u 
o 

1 APPENDIX A 

m 

m 
w 
m 

\* 
m 

o 
o 



Media Object Server (MOS™) 
Protocol v2.6 

MOS Protocol version 2.6 
Document Revision WD-2001 -08-09 

Revision Date Thursday, August 09, 2001 

Copyright Notice 

Copyright 2001 , All Rights Reserved. 

License 

This document is provided to You under the conditions outlined below. These conditions are 
©signed to guarantee the integrity of the MOS™ Protocol and to ensure the compatibility of solutions 
implementing the MOS™ Protocol. Use or implementation of the MOS™ Protocol as described 
fikein, may only occur if You agree to these conditions. Failure to follow these conditions shall void 
ffis license. "You" shall mean you as an individual, or, where appropriate, the company or other 
gfrtity on whose behalf you are using this document, and includes any entity which controls, is 
pntrolled by, or is under common control with You. 

z~. ~ 
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Uou must agree to the following in order to use the MOS™ Protocol: 

y 



1. You can use and implement all or some of the messages defined by the protocol. 

2. You may not modify message names, order of defined tags within a message, tag structure, 
defined values, standards and constants. 

3. You may not process messages in a means that is dependent on non-standard messages, tags 

or structures. 

4. You may add additional tags to messages, but the modified messages must contain the 
defined minimum required tags for each message, in the order defined by this document. 

5. Implementations of the MOS Protocol following the above guidelines may claim to be "MOS™ 
Compatible" or "MOS™ v2.6 Compatible" 

6. If You add additional tags, it is strongly recommended these be included and encapsulated only 
within the provided <mosExternalMetadata> structure and not inserted into the pre-defined 
body of the message. 

7. It is inappropriate to make representations of MOS Compatibility unless you have followed 
these guidelines. 
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MPS is a three year old, evolving protocol for communications between Newsroom Computer 
%stems (NCS) and Media Object Servers (MOS) such as Video Servers, Audio Servers, Still Stores, 
Md Character Generators. The MOS Protocol development is supported through cooperative 
cjllaboration among equipment vendors, software vendors and end users. 

Status of this document 

fnis document reflects changes to the MOS protocol made during the MOS meeting at NAB 2001 
and is referred to as MOS v2.6. Logic and message content of MOS v 2.5 have undergone minor 
Ranges based on agreements reached in the NAB 2001 meeting. Three additional messages and 
6Vie additional data structure have been added to v2.6 and are noted below in bold red. 

How to use this document 

The document contains bookmarks and hyperlinks. The Table of Contents and other areas contain 
underlined. Depending on the viewer application used, clicking or double clicking on underlined links 
should take the viewer to the relevant portion of the document. 



Examples of each MOS message and data structure are included. These messages may be used 
for testing. Developers are encouraged to cut these messages from the document, change the value 
of ID tags as appropriate, and paste the modified messages into validation tools. Other than these 
example messages, validation tools are not provided by the MOS Group. 
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7. Recent Changes 

7.1 Changes from MPS version 2.5 to 2.6 WD-200 1-06-06 

7.2 Changes from MPS version 2.0 to 2.5 WD-2000-08-01 

7.3 Changes for MPS 2.0 WD-1 999-05-1 2 

7.4 Changes from MPS version 1 .52 to 2.0 WD-1 999-03-1 7 
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8. References and Resources 

8.1 MPS Protocol Web Page 

8.2 XML FAP 

8.3 Recommended Reading 

8.4 XML Web Sites 

§ Introduction 

fftis document reflects changes to the MPS protocol made during the MPS meeting at NAB 2001 . 

IJiree new messages and one new data structure were added: mosltem Replace, 
felMetadataReplace , roStorvMove. and mosExternalMetadata. 

K reminder: MOS equipment should ignore, without error, any unknown tags in a message, 
sp long as the message or structure contains properly formatted XML content and the 
minimum subset of required MOS tags for that message or structure. 

t-1 Message Exchange 

Both the NCS and MPS can originate messages. Transmitted messages require a response from 
the receiver before the transmitter will attempt to send the next message in the queue belonging to 
that specific port (either upper or lower). Upper and lower port messages are not related so that 
while a machine is waiting for a response on the lower port it may continue to have a dialog on the 
upper port. 



Note: "Two Ports - Four Sockets" Each pair of communicating machines uses two ports. Each 
machine must be able to accept and handle messages on a minimum of two sockets per port. Pnce 
established, socket connections do not need to be dropped and then re-established between 
messages. Generally, the acknowledgment of a message should be sent down the same socket on 
which the original message was received. However, machines should be able to handle situations in 
which each message arrives in a separate, discrete socket session (though this is not very efficient). 

/-—Socketl 

Lower Port (10540) — < 
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\— -Socket2 



/ — Socketl 

Upper Port (10541)— < 

\— -Socket2 

Note: "Multiple MOS Connections" Each machine (NCS and MOS) should be capable of establishing 
and maintaining connections to multiple systems of the opposite type. e.g. An NCS should be 
capable of connecting to multiple Media Object Servers. Media Object Servers should also be 
capable of connecting to multiple NCSs. 

1.2 Identification 

In practice the MOS and NCS character names are predefined in each system and IP addresses 
associated with each name. 

1.3 Encoding 

The supported character encoding is ISO 10646 (Unicode) in UCS-2, as defined in The Unicode 
standard, version 2.0. All MOS message contents are transmitted in Unicode, high-order byte first. 

M MOS Message Format 

f|e MOS Protocol is fundamentally a tagged text data stream. In the version 2.x, data fields are 
character delimited using Extensible Markup Language (XML™) tags defined in the MOS Data Type 
Definition (DTD). In MOS v1 .x data fields were delimited using a proprietary format. 

2j1 Extensible Markup Language (XML) 

{he syntax of MOS v2.6 is an application of XML, an international standard for describing document 
lintent structure. XML is a simple, flexible text format based on SGML (ISO 8879). XML is an 
abbreviated version of SGML, to make it easier for you to define your own document types, and to 
make it easier for programmers to write programs to handle them. It omits the more complex and 
less-used parts of SGML in return for the benefits of being easier to write applications, easier to 
understand, and more suited to delivery and interoperability over the Web. 



All tags are case sensitive. All MOS messages must be well formed XML, but are not required to be 
valid. 



Each MOS message begins with the root tag ("mos"), followed by the MOS and NCS ID ("mosID" and 
"ncsID"), and followed by the message type. Data follows in tagged form. 



Vendors are encouraged to add CR/LF and Tabs within a message to improve readability for 
debugging purposes. 
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2.2 Message Acknowledgement 

When a message is sent by one device, it will not send another message until it receives an 
acknowledgement ("ACK") or error ("NACK") from the other device. Vendors should reset and/or retry 
when a timeout occurs. 

2.3 Message Transport 

MOS Lower Port (1 0540) is defined as the default TCP/IP port on which the NCS will accept 
connections from MOS devices. Multiple simultaneous connections are supported. This socket is 
referred to as "Media Object Metadata" port in the Message Types section. 



MOS Upper Port (10541) is defined as the default TCP/IP port on which the MOS will accept 
connections from the NCS. Multiple simultaneous connections are supported. This socket is 
referred to as "Running Order" port in the Message Types section. 



Ports 10520 and 10521 were specified as Lower and Upper Ports in previous versions of the MOS 
Plotocol. Beginning in version 2.5 these ports are vendor selectable but site specific. All MOS 
epabled machines within a site or enterprise should communicate using the same ports. 



Because some vendors reported problems using port 10521 with Microsoft Windows NT the new port 
numbers used as examples are now 10540 and 10541 . 



gbr example an NCS initiated create running order command and the MOS' associated ACK would 
flke place on MOS Upper Port (10541). Object updates sent from the MOS and the associated NCS 
KCK would take place on MOS Lower Port (10540). 

2.4 Unknown Tags 

Should a MOS or NCS encounter an unknown message or data tag the device should ignore the tag 
and the data and continue to process the message. Unknown data tags should not generate an 
application error. The application has the option of indicating a warning. 

2.5 Object Description Format 

Object description is restricted to plain Unicode UCS-2 text that includes Tab, CR, LF and the 
optional markup for paragraphs, tabs and emphasis. Formatted text such as HTML, RTF, etc. will no 
be allowed in the unstructured description area. 



2.6 Languages 

Data tags and constants are formatted as English. 
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The only Data Fields that can contain other languages are: 

createdBv 
modifiedBy 
roSlug 
storvSluq 

storvBodv 

itemSluq 

description 



And the data structure mosExternalMetadata 

2.7 Numbers 

Numbers are formatted as their text equivalent, e.g.: 
The decimal number 100 is represented as text "100". 
Hex FF55 is represented as text "0xFF55" or "xFF55". 

2.8 Running Orders 

5 1) Running Order (Unique ID - may appear only once in the NCS) 
Q 2) Story (Unique ID - may appear only once in the RO) 
5 3) Item (Unique ID - may appear only once in a story) 
fIJ 4) Object (Unique ID - may appear only once in an item) 



(rts assumed that all Unique ID's (UID's) created by one machine are respected by others. 



grder of data fields within an item is significant. 

2 K 

Items are sent in the order they should be played. 



Order of items is significant. 



Multiple Running Orders may contain the same Story. 



Running Orders may contain zero or more Stories. 

Multiple stories can contain the same Object referenced by different Items. 



Stories can contain multiple Items. 



Item IDs may appear only once in a Story, but can appear in other Stories. 

Objects can appear multiple times in a Story, but only one object may appear in an Item. 

A Running Order Item is defined by the combination Running Order.Story.ltem and contains the 
UID's of the Running Order, Story and Item which together can identify a unique Item within a 
Running Order. Additions, deletions, and moves within the running order are referenced in this way 
to the Item. 

2.9 Samples 

Still Store and Character Generator media objects are defined as having 1 sample per second. They 
are special cases that require the NCS and MOS applications to understand they do not change 
every second. 

MOS Messages 

In the Structural Outline sections below use of "?" specifies optional element, "+" specifies one or 
rwore of the element, and '""'specifies zero or more of the element. Elements without any of these 
tl-ee special characters are required. 

figs enclosed in parenthesis and separated by T represent a selection. 

fne Syntax section shows the definition of non-terminals for this message from the DTD. 

Samples shown are representative of syntax only and do not represent samples from any system. 

3. Object Messages 

3.1 mosAck - Acknowledge MOS Object Description 
Purpose 

The MOS Acknowledgement for the MOS OBJ message. 

Response 

N/A 

Port 

MOS Lower Port (10540) - Media Object Metadata 
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Structural Outline 

mos 

mosiD 

ncslD 

mosAck 

obilD 

objRev 

status 

statusDescription 
Syntax 

< I ELEMENT mosAck (objID, objRev, status, statusDescription) > 

Example 

<mos> 

<mosID>aircache.newscenter.com</mosID> 
<ncsID>ncs . newscenter . com</ncsID> 
<mosAck> 

<objID>M000123</objID> 
y, < ob j Rev> 1 < / ob j Re v> 

<status>AOC</status> 
5? <statusDescriptionx/statusDescription> 



gontains information that describes a unique MOS Object to the NCS. The NCS uses this 
pformation to search for and reference the MOS Object. 

<objGroup> tag 

No specific values for this element are officially defined. Definition of values is left to the configuration and 
agreement of MOS connected equipment. The intended use is for site configuration of a limited number of 
locally named storage folders in the NCS or MOS, such as "ControlA", "ControlB" , "Raw", "Finished", etc. 
For editorially descriptive "category" information, it is suggested that the <externalMetadata> block be used. 

ExternalMetadata Block 

This data block can appear in several messages as a mechanism for transporting additional metadata, 
independent of schema or DTD. When found within the mosObj message, this block carries data defined 
external to the MOS Protocol. 

External Metadata <scope> tag 

The value of the <scope> tag implies through what production processes this information should travel. 




3,2 mosObj - MOS Object Description 
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A scope of "object" implies this information is generally descriptive of the object and appropriate for 
queries. The metadata should not be forwarded into Stories or Playlists. 



A scope of "story" suggests this information may determine how the Object is to be applied in a 
Story. For instance, Intellectual Property Management. This information should be forwarded with 
the contents of a Story. 



A scope of "playlist" suggests this information is specific to describing how the Object is to be 
published, rendered, or played to air and thus, should be included in the roCreate Play List 
Construction and roStorySend messages. 



Scope allows systems to, optionally, roughly filter external metadata and selectively apply it to 
different production processes and outputs. Specifically, it is neither advisable nor efficient to send 
latge amounts of inappropriate metadata to the Playlist in roCreate messages. In addition to these 
fibcks of data being potentially very large, the media Object Server is, presumably, already aware c 
tSs data. 

Response 

til 

u? 

iSDsAck 
Port 

MOS Lower Port (10540) - Media Object Metadata 
Structural Outline 

mos 

mosID 

ncsID 

mosObi 

obilD 

obiSluq 

mosAbstract? 
obiGroup? 

objType 

| objTB 

| obi Rev 

\ objDur 

j status 

I objAir 

f createdBv 
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created 
chanqedBy 
changed 
description 
(el em | tab)* 

mosExternalMetadata* 
mosScope? 

rnosSchema 

mosPayload 

Syntax 

< ! ELEMENT mosObj (objID, objSlug, mosAbstract , objGroup?, objType, objTB, objRev, objDur, 
status, objAir, createdBy, created, changedBy, changed, description, 
mosExternalMetadata*) > 

< ! ELEMENT description {# PCDATA | p | em | tab) *> 
< I ELEMENT p (# PCDATA | em | tab) *> 

<! ELEMENT mosExternalMetadata (mosScope?, rnosSchema, mosPayload) > 
<pJ3LEMENT mosScope (object | story | playlist) > 
SlELEMENT rnosSchema (# PCDATA) > 
<pELEMENT mosPayload (# PCDATA) > 

Example 

fgos> 

lZ <mosID>aircache .newscenter . com</mosID> 
O <ncsID>ncs .newscenter. com</ncsID> 
r " <mosOb j > 

<obj ID>M000123</obj ID> 
<objSlug>Hotel Fire</objSlug> 
<mosAbstract> 

<b>Hotel Fire</b> 
<em>vo< / em> 
:30 

</mosAbstract> 

<objGroup>Show 7</objGroup> 

<objType>VIDEO</objType> 

<objTB>60</objTB> 

<objRev>l</objRev> 

<objDur>1800</objDur> 
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< s ta tus >NEW< /status > 
<objAir>READY</objAir> 
<createdBy>Chris</createdBy> 
<created>1998-10-31T23 : 39 : 12</created> 
<changedBy>Chris</changedBy> 

< changed> 1 998-10-3 1T23:39:12< /changed> 
<description> 

<p> 

Exterior footage of 
<em>Baley Park Hotel</em> 

on fire with natural sound. Trucks are visible for the first portion of the clip. 
<em>CG locator at 0:04 and duration 0:05, Baley Park Hotel. </em> 

</p> 
<p> 

<tab/> 

^ Cuts to view of fire personnel exiting hotel lobby and cleaning up after the fire is 

ft 
Mb. 

Q </P> 

h! <p> 

y <em>Clip has been doubled for pad on voice over.</em> 

y * </p> 

</description> 

<mosExternalMetadata> 
Pi <mosScope >ST0RY< /mosScope > 

O <mosSchema>http : //M0SA4 .com/mos/supported_schemas/M0SAXML2 . 08</mosSchema> 

<mosPayload> 

< 0 wne r > SHOLME S < / Owne r > 
<ModTime>20010308142001</ModTime> 

<mediaTime > 0 < /medi aTime > 
<TextTime >2 7 8 < /TextTime > 
<ModBy >L J0HNST0N< /ModBy > 
< Approved> 0 < / Appr oved> 
<Creator>SHOLMES</Creator> 
</mosPayload> 
</mosExtemalMetadata> 
</mosObj > 
</mos> 



3.3 mosReqObj - Request Object Description 
Purpose 

Message used by NCS to request object description. 
Response 

mosObi - if objID is found 
mosAck - otherwise 

Port 

MOS Lower Port (10540) - Media Object Metadata 
Structural Outline 

mos 

mosID 
u. ncslD 
m mosReqObj 
6 obi ID 

Syntax 

fjj jj 

ill ELEMENT mosReqObj (objID)> 

Example 

fi°s> 

n <mosID>aircache . newscenter . com</moslD> 
<ncsID>ncs .newscenter . com</ncsID> 
<mosReqOb j > 

<objID>M000123</objID> 

</mosReqObj> 
</mos> 



3.10 Object Resynchronization/Rediscovery 

■ 3.1 1 mosReqAII - Request All Object Data from MOS 

i 

l Purpose 

Method for the NCS to request the MOS send it mosObj messages for every Object in the MOS. 

I 
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Pause, when greater than zero, indicates the number of seconds to pause between MOS objects in 
the rnosListAII message. Pause of zero indicates that all objects should be sent using mosObj 
messages. 

Response 

rnosListAII - if pause > 0 
mosObj - otherwise 

Port 

MOS Lower Port (10540) - Media Object Metadata 
Structural Outline 

mos 

mosID 
ncsID 
mosReqAll 
pause 

Syntax 

few 

^ELEMENT mosReqAll (pause) > 

Example 

Slos> 

111 

2 <mosID>aircache . newscenter . com< /mosID> 

f|J <ncsID>ncs . newscenter . com</ncsID> 

Jj-t <mosReqAll> 

U <pause > 0 < /pause > 

</mosReqAll> 
</mos> 



3.12 rnosListAII - Listing of All Object Data from MOS 

Purpose 

Send MOS object descriptions in a format similar to mosObj sequentially from the MOS to the NCS 
in response to the mosReqAll message. There is a pause between each object as defined in the 
mosReqAll message. 

Response 

None 
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Port 



MOS Lower Port (10540) - Media Object Metadata 
Structural Outline 

mos 

rnosID 

ncsID 

mosListAH 

(objlP, obiSluq, mosAbstract ?, obiGroup?, obiType, obiTB, obiRev, objPur, status, objAir, 
createdBv, created , changedBy , changed , description, mosExternalMetadata*)+ 



Syntax 

<! ELEMENT mosList All ((objID, objSlug, mosAbstract? , objGroup?, objType, objTB, objRev, 
objDur, status, objAir, createdBy, created, changedBy, changed, description, 
mpsExt ernalMet adata* ) * ) > 

U4 ELEMENT description ( # PCDATA | p | em | tab) *> 
3 ELEMENT p (# PCDATA | em | tab) *> 

Example 

y^ios> 

Qnj <mos ID>aircache . newscenter . com</mosID> 

<ncsID>ncs .newscenter . com</ncsID> 
m <mosListAll> 
C <objID>M000123</objID> 
y[ <objSlug>HOTEL FIRE</obj Slug> 

<obj Type>VIDE0</objType> 

<ob j Cat egory >RAW< /ob j Group> 

<objTB>60</objTB> 

<ob j Rev>3 < /ob j Rev> 

<objDur>1530</objDur> 

<status>UPDATED</status> 

<objAir>READY</objAir> 

<createdBy>Chris</createdBy> 

<created>1998-10-31T23 : 39 : 12</created> 

< changedBy >Chr i s < / changedBy > 

<changed>1998-ll-01T14 :35 : 55</changed> 

<description> 
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<p> 

Exterior footage of 
<em>Baley Park Hotel</em> 
on fire with natural sound. Trucks are visible for the first portion of the 

clip. 

<em>CG locator at 0:04 and duration 0:05, Baley Park Hotel. </em> 
</p> 
<P> 

<tab/> 

Cuts to view of fire personnel exiting hotel lobby and cleaning up after the 

Irire is out. 

m < /^ > 

w <p> 

CSS 

m <em>Clip has been doubled for pad on voice over.</em> 

M> </ ' p> 

l'^ </description> 

p <obj ID>M000224</obj ID> 

D 

r: <objSlug>COLSTAT MURDER: VO</objSlug> 

<ob j Type>VIDEO</ob j Type> 
<objTB>60</objTB> 
<ob j Rev>4 < /ob j Rev> 
<ob j Dur > 8 0 0 < /ob j Dur > 
<status>UPDATED</status> 

< ob j Ai r > RE AD Y< /ob j Ai r > 
<createdBy>Phil</createdBy> 
<created>1998-ll-01T15 : 19 : 01</created> 

< changedBy >Chr i s < / changedBy > 
<changed>1998-ll-01T15 : 21 : 15</changed> 

<description>VOICE OVER MATERIAL OF COLSTAT MURDER SITES SHOT ON 
1-NOV. </description> 



nf79 
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<mosExternalMetadata> 

<mosScope>STORY</mosScope> 

<mosSchema>http : / /M0SA4 . com/mos/ support ed_schemas/M0SAXML2 . 0 8</mosSchema> 
<mosPayload> 

<Owner>SH0LMES< /Owner > 
<ModTime>2 001 0308142 001</ModTime> 
<mediaTime>0</mediaTime> 
<TextTime >2 7 8 < /TextT ime > 
<ModBy >L JOHNSTON< /ModBy > 
<Appr ove d > 0 < / Appr oved> 
<Creator>SHOLMES</Creator> 
< /mosPayload> 
</mosExternalMetadata> 
</mosListAll> 
Q'mos> 

□ 

1.20 Object and item management 

y ? 

3.21 mosObjCreate - MOS Object Create 
(Purpose 

Hlows an NCS to request the Media Object Server to create a Media Object with specific metadata 
associated with it. 

Response 

rnosAck (if object can be created then status description = objID) 

NACK (if object CANNOT be created, status description = reason for error) 

mosObi 

Port 

MOS Lower Port (10540) - MOS Object 
Structural Outline 

mos 

mosiD 
ncslD 

mosObjCreate 
objSluq 
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objGroup? 

obiTB 

obiDur ? 

time? 

created By ? 
description ? 

mosExternalMetadata* 

Syntax 

< I ELEMENT mosObj Create (objSlug, objGroup?, objType, objTB, objDur?, time?, createdBy?, 

description? , mosExternalMetadata* ) > 

< i ELEMENT description (# PCDATA | p | em | tab)*> 

<i ELEMENT p (# PCDATA | em | tab) *> 

Example 

gmos> 

^ <mosID>videoserver . station . com</mosID> 
0 <ncsID>ncs . stat ion. com</ncsID> 
ff I <mosObjCreate> 

S <objSlug>Hotel Fire</obj Slug> 

IP 

s <objGroup>Show 7</objGroup> 

hi <objType>VIDEO</objType> 
!Z <ob j TB > 6 0 < /ob j TB> 

O <objDur>1800</objDur> 

<createdBy >Chris</createdBy> 

<description> 
<p> 

Exterior footage of 
<em>Baley Park Hotel</em> 
on fire with natural sound. Trucks are 
visible for the first portion of the clip. 

<em>CG locator at 0:04 and duration 0:05, Baley Park 
Hotel . </em> 
</p> 
<p> 

<tab/> 
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Cuts to view of fire personnel exiting hotel lobby and cleaning up after the 

fire is out. 

</p> 
<p> 

<em>Clip has been doubled for pad on voice over.</em> 

</p> 
</description> 
<mosExternalMetadata> 

<mosScope>STORY</mosScope> 

<mosSchema>http: //NCSA4 . com/ mo s/supported_s enema s/NCSAXML2 . 08</mos Schema > 
<mosPayload> 

<Owner>SHOLMES</Owner> 
<ModTime>2 0010308142 00 l</ModTime> 
<mediaTime>0</mediaTime> 
^ <TextTime>278</TextTime> 
P <ModBy >L JOHNSTON< /ModBy > 

ji* <Approved>0</Approved> 
\& <Creator>SHOLMES< /Creator > 

s ~ i; 

If! </mosPayload> 

y= < /mosExternalMetadat a> 

:*f </mosObj Create > 

£^mos> 

3.22 mosltemReplace - Replace one Item Reference with another 

Purpose 

This message allows a media Object Server to replace an Item Reference in a Story with new 
metadata values and/or additional tags. The Story must be in a MOS Active Play List. Thus, this 
message is in the "ro" family of messages rather than the "mos," or lower port, family. However, this 
message is initiated by the media Object Server, rather than the NCS. 

Behavior 

This message must reference as existing unique Item Reference in a MOS Active Play List through 
the values of ncsID, rolD, storylD, and itemlD. 
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If metadata tags in the mosltemReplace message already exist in the target Item Reference, values 
within the Item Reference will be replaced by the values in the mosltemReplace message. 



If the metadata tags do not already exist in the target Item Reference they will be added. 



If a mosExternalMetadata block is included in the mosltemReplace message, it will replace an 
existing mosExternalMetadata block only if the values of <mosSchema> in the two blocks match, 
and only for the first occurrence of a block with a matching <mosSchema> tag. Otherwise the 
mosExternalMetadata block will be added to the target Item Reference. 



If the ItemID in the mosltemReplace message does not match an existing ItemID in the specified 
Story then no action will be taken and the mosltemReplace message will be replied to with an roAck 
message specifying the Item values in the mosltemReplace message and carrying a status value of 
"NACK." 

Response 

MAck 

EbStorvReplace 
plStorySend 
Subsequent messages 

i 

feStoryReplace - A successful mosltemReplace operation will result in a change to an Item 
inference embedded in a Story. This new information must now be placed in associated MOS 
Baylists. The roStoryReplace message will replace the old item reference in the playlist with the 
Newly updated item reference from this Story. 

roStorySend - A successful mosltemReplace operation will result in a change in the body of a Story. 
This change must be sent back out if an roStorySend target has been defined for the RO. 

Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

mosID 
ncsID 

mosltemReplace 
rolD 
storylD 

item * 

item ID 
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itemSlug ? 



objiD 
mosiD 



mosAbstract ? 

itemChannel ? 

itemEdStart? 

itemEdPur ? 

itemTrigger ? 

macroln ? 

macroOut? 

mosExternalMetadata* 

Syntax 

<! ELEMENT mosItemReplace (roID, storylD, item) > 

< 'ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, itemChannel?, 
itemEdStart?, itemEdDur?, itemTrigger?, macroln?, macroOut?, mosExternalMetadata* 

<! ELEMENT mo s External Metadata (mosScope?, mosSchema, mosPayload) > 

Example 

asst. 

<£mos> 

5 I <mosID>aircache . newscenter . com</mosID> 

i y 

fij <ncsID>ncs . newscenter . com</ncsID> 

ff% 

<mosItemReplace> 

<roID>5PM</roID> 

S I I 

pi < story ID>HOTEL FIRE</storyID> 
pi <item> 

I 3 * <itemID>3 084 8</itemID> 

<objID>M000627</objID> 
<mosID>testmos .enps , com</mosID> 
<itemEdStart>0</itemEdStart> 
< i t emEdDur >815</it emEdDur > 
<macroln>c01/104/dve07</macroln> 
<macroOut>rOO< /macroOut > 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>HTTP; / /WENDOR/MOS/supportedSchemas/wend2 80</mosSchema> 

<mosPayload> 

<trigger>83 7</trigger> 



<key>110</key> 
<f ade>17</fade> 
<efxTime>15</efxTiine> 
</mosPayload> 
< /mosExternalMetadat a> 
</item> 
</mosItemReplace> 
</mos> 



4. ro (Running Order) basic messages for playlist construction 

4.1 roAck - Acknowledge Running Order 
Purpose 

MOS response to receipt of any Running Order command. 

Response 

None 

Port 

ROS Upper Port (10541) - Running Order 
Structural Outline 



mos 

mosID 
ncsID 
roAck 
rolD 

roStatus 

( storylD , itemID, obi ID , status )* 
Syntax 

<! ELEMENT roAck (rolD, roStatus, (storylD, itemID, objID, status) *)> 

Example 

<mos> 

<mosID>aircache .newscenter . com</mosID> 
<ncsID>ncs . newscenter . com</ncsID> 
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<roAck> 

<roID>96857485</roID> 

<roStatus>Unknown object M000133</roStatus> 
<storyID>5983A501: 0049B924 : 8390EF2B</storyID> 
<itemID>0</itemID> 
<obj ID>M000224</obj ID> 
<status>LOADED</status> 

<storyID>3854737F: 0003A34D : 983A0B28</storyID> 
<itemID>0</itemID> 
<obj ID>M000133</obj ID> 
<status>UNKNOWN</status> 
</roAck> 
</mos> 



#2 roCreate - Create Running Order 

Purpose 

ill 

Ifessage from the NCS to the MOS that defines a new Running Order. 
Response 

rjAck 
6>rt 

MOS Upper Port (10541) - Running Order 
Structural Outline 



mos 

rnosiD 

ncsID 

roCreate 

rolD 

roSlug 

roChannel? 

roEdStart? 

roEdDur ? 

roTriqqer ? 

rnacroln? 



macroQut? 



mosExternal Metadata * 
story * 

story! D 

storvSluq? 

storvNum? 

mosExternalMetadata* 
item * 

itemlD 

itemSlug? 

obilD 

moslD 

mosAbstract ? 

itemChannel ? 
itemEdStart? 
iternEdDur? 
itemTriqger? 
macroln ? 
U macroOut ? 

O mosExternalMetadata * 

sss. 

Syntax 

kl ELEMENT roCreate (roID, roSlug, roChannel? , roEdStart?, roEdDur? , roTrigger? , macroln?, 
fpicroOut?, mosExternalMetadata*, story*) > 

f I ELEMENT story (storylD, storySlug?, storyNum?, mosExternalMetadata*, item*) > 

ELEMENT item (itemlD, itemSlug?, objID, moslD, mosAbstract?, itemChannel?, 
ItemEdStart?, iternEdDur?, itemTrigger? , macroln?, macroOut?, mosExternalMetadata* ) > 

Ixample 

k&ios> 

<mosID>aircache .newscenter .com</mosID> 
<ncsID>ncs . newscenter . com</ncsID> 
<roCreate> 

<roID>96857485</roID> 

<roSlug>5PM RUNDOWN</roSlug> 

<roEdStart>1999-04-17T17 : 02 : 00</roEdStart> 

<roEdDur>00 : 58 : 25</roEdDur> 

<story> 

<StoryID>5983A501 : 0049B924 : 83 90EF2B</storyID> 
<storySlug>COLSTAT MURDER</storySlug> 
< s toryNum>A5 < / storyNum> 
<item> 
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<itemID>0</itemID> 

<itemSlug>COLSTAT MURDER : VO</i temS lug > 
<obj ID>M000224</obj ID> 
<mosID>testmos . enps . com</mosID> 

< i t emEdDur >645</it emEdDur > 
<itemTrigger>CHAINED</itemTrigger> 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http : / / M0SA4 . com/mos/supported_schemas/M0SAXML2 . 08</mos Schema > 
<mosPayload> 

<Owner>SHOLMES</Owner> 

< t r ans i t i onMode > 2 < / 1 r ans i t ionMode > 

< t rans it ionPo int > 4 6 3 < / 1 r ans i t ionPo int > 
<source>a</source> 
<destination>b</destination> 

</mosPayload> 
</mosExternalMetadata> 
</item> 
/story> 
story> 

<StoryID>3854737F:0003A34D:983A0B28</storyID> 
<storySlug>AIRLINE INSPECTIONS</storySlug> 
<storyNum>A6</storyNum> 
<item> 

<itemID>0</itemID> 

<obj ID>M000133</obj ID> 

<mosID>testmos . enps . com</mosID> 

<itemEdStart>55</itemEdStart> 

< i t emEdDur >310</it emEdDur > 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http : / /M0SA4 . com/mos/supported_schemas/M0SAXML2 . 08</mosSchema> 
<mosPayload> 

< 0 wne r > SHOLME S < / Owne r > 
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< t r ans i t i onMode > 2 < / 1 rans i t i onMode > 
<transitionPoint>4 63 </ transit ionPoint> 
<source>a</source> 
<des t inat ion>b< / dest inat ion> 
< /mosPayload> 
</mosExternalMetadata> 
</item> 
</story> 
</roCreate> 
</mos> 



4.3 roReplace - Replace Running Order 

Purpose 

Replaces an existing Running Order definition in the MOS with another one sent from the NCS. 



Response 




Bprt 



pOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

mosID 

ncsID 

roReplace 

rolD 

roSlug 

roChannel ? 

roEdStart? 

roEdDur ? 

roTrigger ? 

macroln ? 
macroQut? 

mosExternalMetadata * 
story * 
story ID 
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storvSlug? 



ston/Num ? 

rnosExternalMetadata * 
item* 

itemiP 

itemSlug ? 

obilP 

rnosiP 

mosAbstract ? 

itemChannel? 

itemEdStart? 

itemEdDur ? 

itemTrigger ? 

macro In ? 

macroOut ? 

rriosExtemaliVletadata* 

Syntax 

Q ELEMENT roReplace (roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, 
fiiicroln?, macroOut?, rnosExternalMetadata*, story*) > 

*fj ELEMENT story ( storylD , storySlug? , storyNum? , rnosExternalMetadata* , item* ) > 
Si ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, itemChannel?, 
SfemEdStart?, itemEdDur?, itemTrigger?, macroln? , macroOut?, rnosExternalMetadata*) 

Example 

fmos> 

a 

y* <mosID>aircache . newscenter . com</mosID> 
pi <ncsID>ncs .newscenter . com</ncslD> 
^ <roReplace> 

<roID>9685 7485</roID> 

<roSlug>5PM RUNDOWN</roSlug> 

<story> 

<StoryID>5983A501 : 0049B924 : 8390EF2B</storyID> 

< s t oryS 1 ug > COLSTAT MURDER< / s t o ry S lug > 

< s t oryNum>Al < / st oryNum> 
<item> 

<itemID>0</itemID> 

< i t emS lug > COLSTAT MURDER : VO< /it emS lug > 
<obj ID>M000224</obj ID> 
<mosID>testmos . enps . com</mosID> 



< i t emEdDur > 6 4 5 < / i t emEdDur > 
<itemTrigger>CHAINED</itemTrigger> 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //M0SA4 . com/Tnos/supported_schemas/M0SAXML2 . 08< /mo s Schema > 
<mosPayload> 

< Owne r>SHOLMES</ 0 wne r > 

< t r ans i t i onMo de > 2 < / 1 r ans i t i onMode > 
<transitionPoint>463</transitionPoint> 
<source>a< /source> 
<destination>b</destination> 

</mosPayload> 
< /mosExternalMetadata> 
</item> 
</story> 
<story> 

<StoryID>3852737F:0013A64D: 923A0B28</storyID> 
<storySlug>AIRLINE SAFETY</storySlug> 
<storyNum>A2</storyNum> 
<item> 

<itemID>0</itemID> 

<obj ID>M000295</obj ID> 

<mosID>testmos . enps . com</mosID> 

< i temEdSt art >5 0 0 < / it emEdS t art > 

< i t emEdDur > 6 0 0 < / i t emEdDur > 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http : / /MOSA4 . com/mo s/supported_s enemas /MOSAXML2 . 08</mosSchema> 
<mosPayload> 

<Owner>SH0LMES</Owner> 

< t r ans i t i onMode > 2 < / 1 r ans i t i onMode > 
<transitionPoint>463</transitionPoint> 
<source>a< / source> 
<destination>b</destination> 
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</mosPayload> 
< /mosExternalMetadata> 
</item> 
</story> 
</roReplace> 

</mos> | 

4.4 roMetadataReplace - Replace RO metadata without deleting the RO structure 
Purpose 

This message allows metadata associated with a running order to be replaced without deleting the 
running order and sending the entire running order again. 

Behavior 

f his message must reference an existing running order 

llmetadata tags in the roMetadataReplace message already exist in the target 

gb, values within the RO will be replaced by the values in the roMetadataReplace message. 

m 

s 

ffjthe metadata tags do not already exist in the target RO they will be added. 

iia mosExternalMetadata block is included in the roMetadataReplace message, it will replace an 
existing mosExternalMetadata block only if the values of mosSchema in the two blocks match. 
Otherwise the mosExternalMetadata block will be added to the target RO. 

If the ROID in the roMetadataReplace message does not match an existing ROID then no action will 
be taken and the roMetadataReplace message will be replied to with an roAck message which 
carrying a status value of "NACK." 

Response 

roAck 
Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 
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mos 

moslD 
ncsID 

roMetadataReplace 
rolD 
roSluq 
roChannel? 
roEdStart? 
roEdDur? 
roTrigger? 

roMacroln ? 

roMacroOut? 

mosExternai Metadata? 

Syntax 

< 'ELEMENT roMetadataReplace (roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, 
rpMacroIn? , roMacroOut ? , mosExternalMetadata? ) > 



Example 

o 

2hos> 

y i 

: ~ <mosID>aircache . newscenter . com</mosID> 
<ncsID>ncs .newscenter . com</ncsID> 

*7 <roMetadataReplace> 

I'd 

H <roID>96857485</roID> 

O <roSlug>5PM RUNDOWN</roSlug> 

<roEdStart>1999-04-17T17 : 02 : 00</roEdStart> 

< r oEdDur >00:58:25</ r oEdDur > 

<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //M0SA4 . com/mos/ support ed_schemas/MOSAXML2 . 08</mosSchema> 
<mosPayload> 

<Owner>SHOLMES</Owner> 

< t r ans i t i onMode > 2 < / 1 r ans i t ionMode > 

< trans it ionPoint >4 6 3 < / transit ionPoint > 

< source>a< / source > 
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<destination>b</destination> 
</mosPayload> 
< /mo s Ext e rna lMe t ada t a > 
</roMetadataReplace> 
</mos> 



4.5 roDelete - Delete Running Order 
Purpose 

Deletes a Running order in the MOS. 
Response 

fijAck 
tiprt 

jtfOS Upper Port (10541) - Running Order 
Structural Outline 

ffios 

M 8 mosID 
O ncsID 
B roDelete 
rolD 

Syntax 

<! ELEMENT roDelete (roID)> 

Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 
<ncsID>ncs . newscenter . com</ncsID> 
<roDelete> 

<roID>494782 85</roID> 
</roDelete> 
</mos> 



4.10 ro Synchronization, Discovery and Status 

4.11 roReq - Request Running Order 
Purpose 

Request for a complete build of a Running Order Playlist. 
NOTE: This message can be used by either NCS or MOS 

A MOS can use this to "resync" it's Playlist with the NCS Running Order or to obtain a full 
description of the Playlist at any time. 

An NCS can use this as a diagnostic tool to check the order of the Playlist constructed in the 
MOS versus the sequence of Items in the Running Order. 

Response 

reList or roAck (roAck with a NACK value is sent if the Running Order ID is not valid or roList cannot 
f?e returned for some reason) 

|ort 

IfOS Upper Port (10541) - Running Order 
Structural Outline 

H mosiD 
P ncsiD 
O roReq 
^ roID 

Syntax 

< l ELEMENT roReq (roID) > 

Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 
<ncsID>ncs .newscenter . com</ncsID> 
<roReq> 

<roID>96857485</roID> 
</roReq> 
</mos> 
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4.12 roList - List Running Order 

Purpose 

A complete build or rebuild of a Running Order Playlist in response to an roReq message. 
NOTE: This message can be sent by either the NCS or MOS 

A MOS can use this to "resync" it's Playlist with the NCS Running Order or to obtain a full 
description of the Playlist at any time. 

An NCS can use this as a diagnostic tool to check the order of the Playlist constructed in the 
MOS versus the sequence of Items in the Running Order. 

roList is functionally similar to roCreate. 

Response 

None 

lft)S Upper Port (10541) - Running Order 
Structural Outline 

x$sx 

IS? " 

raos 

HnioslD 
furiosi D 
tiroList 



roSiug 

roChannel? 

roEdStart? 

roEdDur ? 

roTrigqer ? 

macrofn? 

macroOut? 

mosExternalMetadata* 
story* 

storylD 

storvSlua ? 

storvNum? 

mosExternalMetadata* 
item* 
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item ID 
itemSlug ? 
obilD 
mosID 

mosAbstract ? 

iteniChannel? 

itemEdStart ? 

itemEdDur ? 

iternTrigqer ? 

macroin? 

macroQut ? 

mosExternalMetadata * 

Syntax 

<• ELEMENT roList (roID, roSlug, roChannel?, roEdStart?, roEdDur? , roTrigger? , macroin?, 
macroOut?, mosExternalMetadata*, story*) > 

< I ELEMENT story (storylD, storySlug?, storyNum?, mosExternalMetadata* , item*)> 
< i ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, itemChannel? , 
itemEdStart?, itemEdDur?, itemTrigger? , macroin?, macroOut?, mosExternalMetadata*) > 

Example 

<Bos> 

m <mosID>aircache . newscenter . com</mosID> 
S <ncsID>ncs .newscenter . com</ncsID> 

y § 

sh <roList> 

kj <roID>96 85 7485</roID> 

fT <roSlug>5PM RUNDOWN</roSlug> 



<story> 

<storyID>5983A501 : 0049B924 : 8390EF2B</storyID> 
<storySlug>Colstat Murder</storySlug> 
<storyNum>B10</storyNum> 
<item> 

<itemID>0</itemID> 

< itemS lug>COLSTAT MURDER: VO</ itemSlug > 

<objID>M000224</objID> 

<mosID>testmos .enps . com</mosID> 

<itemEdDur>645</itemEdDur> 

< itemTrigger >CHAINED< / itemTrigger > 

<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 
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<mosSchema>http : //M0SA4 . com/mos / support ed_schemas/M0SAXML2 . 08</mosSchema> 
<mosPayload> 

<Owner>SHOLMES</Owner> 
< t rans i t i onMode > 2 < / 1 r ans i t i onMode > 
<transitionPoint>463</transitionPoint> 
<source>a</source> 
<destination>b</destination> 
</mosPayload> 
</mosExternalMetadata> 
</item> 
</story> 
<story> 

<storyID>3854737F: 0003A34D : 983A0B28</storyID> 

<storySlug>Test MOS</storySlug> 
y <storyNum>Bll</storyNum> 
Q <item> 

ff'z 

Zl <itemID>0</itemID> 

i Li 

W <obj ID>M000133</obj ID> 

« <mosID>testmos .enps . com</mosID> 

< i t emEdS t art > 5 5 < / i t emEdS t ar t > 
H < i t emEdDur >310</it emEdDur > 

p <mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http : / /M0SA4 . com/mos/ support ed_schemas/M0SAXML2 . 0 8 </mos Schema > 
<mosPayload> 

<Owner>SHOLMES</Owner> 
<transiti onMode >2</transiti onMode > 
<transitionPoint>463</transitionPoint> 
< source >a</source> 
<destination>b</destination> 
</mosPayload> 
< /mosExternalMetadata> 
</item> 
</story> 
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</roList> 
</mos> 



4.13 roReqAII - Request All Running Order Descriptions 
Purpose 

Request for a description of all Running Orders known by a NCS from a MOS. 
Response 

roListAII 
Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mbs 

jj moslD 
S ncsID 
nl roReqAII 

Syntax 

<i ELEMENT roReqAII EMPTY > 

||cample 

|ifios> 

N <mosID>aircache . newscenter . com</mosID> 

<ncsID>ncs . newscenter . com< / ncsID> 

< roReqAII/ > 
</mos> 

4.14 roListAII - List All Running Order Descriptions 

Purpose 

Provides a description of all Running Orders known by a NCS to a MOS. 

Response 

None 



Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

moslD 

ncslD 

roListAll 

(rglD, roSlug?, roChannel?, roEdStart?, roEdDur?, roTriqqer?, mosExternalMetadata*)* 
Syntax 

< I ELEMENT roListAll ( (roID, roSlug?, roChannel?, roEdStart?, roEdDur?, roTrigger?, 
mosExternalMetadata*) *) > 

Example 

<mos> 

y, <mosID>aircache . newscenter . com</mosID> 
5 <ncsID>ncs .newscenter . com</ncsID> 
y <roListAll> 

pj <roID>5PM</roID> 

lii 

Jfk <roSlug>5PM RUNDOWN</roSlug> 

- 

? < r oEdDur > 1 7 3 3 < / r oEdDur > 

fy <roEdTrigger>MANUAL</roEdTrigger> 

fs% <mosExternalMetadata> 

U <mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //ncsA4 . com/mos/ support ed_schemas/NCSAXML2 . 08 </mos Schema > 

<mosPayload> 

< Owne r > SHOLME S < / O wne r > 

<ModTime>2 0 010308142 001</ModTime> 

<mediaTime>0</mediaTinie> 

<TextTime>278</TextTime> 

<ModBy >L JOHNSTON< /ModBy> 

<Approved>0</Approved> 

<Creator>SHOLMES</Creator> 
</mosPayload> 
</mosExternalMetadata> 
<mosExternalMetadata> 
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<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //ncsA4 . com/mos/ support ed_schemas/NCSBBBBXML2 . 08</mosSchema> 
<mosPayload> 

< show> 1 Opm< / show> 
<client>network ctrl b</client> 
</mosPayload> 
< /mosExternalMetadata> 
</roListAll> 
</mos> 



4.15 roStat - Status of a MOS Running Order 
Purpose 



Method for the MOS to update the NRC on the status of Play List. This allows the NRC to reflect the 
flatus of the Play List in the NRC Running Order Display. 

Response 

31 

Port 

fiOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

mosiD 

ncsiD 

roStat 

rolD 

status 

time 

Syntax 

<! ELEMENT roStat (rolD, status, time) > 

Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 
<ncsID>ncs.newscenter,com</ncsID> 
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<roStat> 

<roID>5PM</roID> 
<status>MANUAL CTRL</status> 
<time>19 99-04-HT14:22 :0 7</time> 

</roStat> 
</mos> 



4.16 roReadyToAir - Identify a Running Order as Ready to Air 

Purpose 

The message allows the NCS to signal the MOS that a Running Order has been editorially approved 
ready for air. 

Response 

mAck 
F§>rt 

ipS Upper Port (10541) - Running Order 
Structural Outline 

mps 

RimosID 
U noslD 

h roReadyToAir 
0 roifi 
U roAir 

Syntax 

<! ELEMENT roReadyToAir (roID, roAir) > 

Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 
. <ncsID>ncs .newscenter . com</ncsID> 
< r oReadyToAi r > 

<roID>5PM</roID> 

< r oAi r> READY < / roAi r > 
< / roReadyToAir > 
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</mos> 



4.2 ro Story Sequence Modification 

4.21 roStoryAppend - Append Stories to Running Order 
Purpose 

Appends stories and all of its defined items at the end of a running order. 



Response 

roAck 



Port 

[jOS Upper Port (10541) - Running Order 



Structural Outline 

tSjos 

I* mosID 
u. ncs!D 

pi roStoryAppend 

O story * 
O story! D 
M* storvSlug? 

storyNum? 

mosExternalMetadata * 
item * 

item ID 

iternSiuq ? 

obi ID 

mosID 



mosAbstract ? 
itemChannel ? 
itemEdStart? 
itemEdDur? 

ifemTrigger? 

macroln ? 

macroOut? 
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mosExternalMetadata* 



Syntax 

< 1 ELEMENT roStoryAppend { roID , story + ) > 

< I ELEMENT story (storylD, storySlug?, storyNum?, mosExternalMetadata*, item*)> 
< ! ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract? , itemChannel? , 
itemEdStart?, itemEdDur?, itemTrigger? , macroln?, macroOut?, mosExternalMetadata*) > 

Example 

<mos> 

<mosID>aircache . newscenter . com< /mosID> 
<ncsID>ncs .newscenter . com</ncsID> 
<roStoryAppend> 

<roID>5PM</roID> 

<story> 

<storyID>V: BRIDGE COLLAPSE</storyID> 
O <storySlug>Bridge Collapse</storySlug> 

Si <storyNum>B7</storyNum> 
z.1 <item> 

yj <itemID>3 0848</itemID> 

<objID>M00062 7</objID> 
<mosID>testmos . enps . com</mosID> 

ii ?£■ 

fa£ < i t emEdS t ar t > 0 < / i t emEdS t art > 

S < i t emEdDur >815</it emEdDur > 

^ <macroln>c0l/104/dve0 7</macroln> 

<macroOut >r0 0 < /macroOut > 

<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //M0SA4 . com/mos/ support ed_schemas/M0SAXML2 . 08</mos Schema > 
<mosPayload> 

< Owne r > S HOLME S < / Owne r > 

< trans it ionMode>2 < /trans it ionMode > 

< transit ionPoint>4 63 </transitionPoint> 

<source>a</source> 

<destination>b</destination> 
</mosPayload> 
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< /mosExternalMetadata> 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //M0SA4 . com/mo s/ support ed_schemas/MOSBXML2 . 0 8 </mos Schema > 
<mosPayload> 

<rate>52</rate> 
<background>2 < /background> 
<overlay>463</overlay> 
</mosPayload> 
</mosExternalMetadata> 
</item> 
<item> 

<itemID>3 0849</itemID> 
<objID>M00062 8</objID> 
p <itemEdStart>0</itemEdStart> 
S < i t emEdDur >815</it emEdDur > 

J:"; <macroln>c01/104/dve07</macroln> 

ry 

Ui <macroOut >r00 < /macroOut > 

fn 

<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

fy 

M= <mosSchema>http : //M0SA4 . com/mos/supported_schemas/M0SAXML2 . 08</mosSchema> 

f4 <mosPayload> 

<Owner>SHOLMES</Owner> 
< t r ans i t i onMode > 2 < / 1 r ans i t ionMode > 
<transitionPoint>463</transitionPoint> 
<source>a</ source> 
<destination>b</destination> 
</mosPayload> 
< /mosExternalMetadata> 
</item> 
</story> 
</roStoryAppend> 
</mos> 
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4.22 roStorylnsert - Insert Stories in Running Order 
Purpose 

Inserts stories and all of its defined items before the referenced Story in the running order. 

Response 

roAck 

Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

mosID 
ncsID 

roStorylnsert 
■!? rolD 



n stQr yiD 

S story+ 
Si story ID 
[j storySlug? 

pi 

g storvNurn ? 

111 mosExternalMetadata * 
H item * 
O item ID 
O itemSiug ? 
M : objlD 
mosID 

mosAbstract? 

itemChannel? 

itemEdStart? 

itemEdDur ? 

itemTrigqer ? 

macroln ? 

macroOut ? 

mosExternalMetadata* 



Syntax 

< I ELEMENT roStorylnsert (roID, storylD, story+)> 

< ! ELEMENT story (storylD, storySlug?, storyNum?, mosExternalMetadata*, item*)> 
< 1 ELEMENT item (itemID, itemSiug?, objID, mosID, mosAbstract?, itemChannel?, 
itemEdStart?, itemEdDur?, itemTrigger? , macroln?, macroOut?, mosExternalMetadata* ) > 



Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 
<ncsID>ncs .newscenter . com</ncsID> 
<roStoryInsert> 

<roID>5PM</rolD> 

<storyID>HOTEL FIRE</storyID> 

<story> 

<storyID>V: BRIDGE COLLAPSE</storyID> 

<storySlug>Bridge Collapse</storySlug> 

< s toryNum>B7 < /s t oryNum> 

<item> 

<itemID>3 0848</itemID> 
<obj ID>M000627</obj ID> 
y <mosID>testmos .enps . com</mosID> 

|p <itemEdStart>0</itemEdStart> 
I Ij < i t emEdDur >815</it emEdDur > 

w ' <macroln>c01/104/dve07</macroln> 
M> <macroOut>rOO</macroOut> 
LI <mosExternalMetadata> 
y <mosScope>PLAYLIST</mosScope> 

mi 

1*1 <mosSchema>http : / /M0SA4 . com/mos/ support ed_schemas/M0SAXML2 . 08</mosSchema> 

<mosPayload> 

<Owner>SH0LMES</Owner> 
< t r ans i t i onMode >2 < / 1 rans i t ionMode > 
<transitionPoint>463</transitionPoint> 
<source>a</source> 
<des t inat ion>b< /dest inat ion> 
</mosPayload> 
</mosExternalMetadata> 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //M0SA4 . com/mos /supported_schemas/M0SBXML2 . 08</mosSchema> 
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<mosPayload> 

<rate>52</rate> 
<background>2 < /background> 
<overlay>463</overlay> 
</mosPayload> 
< /mosExternalMetadata> 
</item> 
<item> 

<itemID>3084 9</itemID> 

<obj ID>M000628</obj ID> 

<itemEdStart>0</itemEdStart> 

<itemEdDur>815</itemEdDur> 

<macroln>c01/104/dve07</macroln> 

<macroOut >r 0 0 < /macroOut > 

i t 

f"S <mo s Ext e r nal Me t ada t a > 

Jj: <mosScope>PLAYLIST</mosScope> 

ffl <mosSchema>http: //MOSA4 . com/mos/ support ed_schemas/MOSAXML2 . 08</mos Schema > 

\i\ <mosPayload> 

ft* 

<Owner>SHOLMES< /Owner > 
H < t r ans i t ionMode > 2 < / 1 r ans i t ionMode > 

yi. <transitionPoint>4 63 </ transit ionPoint> 

zZ <source>a</source> 
H < de s t ina t ion >b < /de s t ina t i on> 

</mosPayload> 
</mosExternalMetadata> 
</item> 
</story> 
</roStoryInsert> 
</mos> 

4.23 roStoryReplace - Replace Story with Another in a Running Order 

Purpose 

Replaces the referenced story with another story or stories and all of its associated Items in the 
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Running Order. 



Response 

roAck 
Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

moslD 
ncslD 

roSton/Replace 
rolD 
storylD 
storv + 

storylD 

storvSluq? 

2 storvNum ? 

y mosExternalMetadata * 
% item * 
H item ID 
m itemSlug ? 

obi ID 
u moslD 



mosAbstract? 

itemChannel ? 

itemEdStart? 

itemEdDur ? 

itemTrigger? 

macroln? 

macroOut? 

mosExfernalMetadata * 



Syntax 

< ! ELEMENT roStoryReplace (rolD, storylD, story+) > 

< ! ELEMENT story (storylD, storySlug?, storyNum?, mosExternalMetadata*, item*)> 
<! ELEMENT item (itemID, itemSlug?, objID, moslD, mosAbstract?, itemChannel?, 
itemEdStart?, itemEdDur?, itemTrigger?, macroln?, macroOut?, mosExternalMetadata*) > 

Example 



<mos> 

<mosID>aircache . newscenter . com</mosID> 



<ncsID>ncs .newscenter , com</ncsID> 
<roStoryReplace> 
<roID>5PM</roID> 

<storyID>P: PHILLIPS INTERVIEW</storyID> 
<story> 

<storyID>V: HOTEL FIRE</storyID> 
<storySlug>Hotel Fire</storySlug> 
< storyNum>Cl</storyNum> 
<item> 

<itemID>3 0848</itemID> 

<itemSlug>Hotel Fire vo</itemSlug> 

<objID>M000702</objID> 

<mosID>testmos</mosID> 

<itemEdStart>0</itemEdStart> 

< i t emEdDur >900</it emEdDur > 

<macroln>c01/104/dve0 7</macroln> 

<macroOut >r0 0< /macroOut > 

<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //M0SA4 . com/mos/supported_schemas/MOSAXML2 . 08</mosSchema> 
<mosPayload> 

<Owner>SHOLMES</Owner> 
< t r ans i t i onMode > 2 < / t r ans i t ionMode > 
<transitionPoint>4 63 < /transit ionPoint> 
<source>a</ source> 
<destination>b</destination> 
< /mosPayload> 
</mosExternalMetadata> 
</item> 
</story> 
<story> 

<storyID>V: DORMITORY FIRE</storyID> 
<storySlug>Dormitory Fire</storySlug> 
<storyNum>C2</storyNum> 
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<item> 

<itemID>l</itemID> 

<itemSlug>Dormitory Fire vo</itemSlug> 
<obj ID>M000705</obj ID> 
<mosID>testmos</mosID> 
<itemEdStart>0</itemEdStart> 
< i t emEdDur >800</it emE dDur > 
<macroln>c01/104/dve07</macroln> 
<ma c r oOu t >r00</mac r oOu t > 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //M0SA4 . com/mos/ support ed_scheraas/MOSAXML2 . 0 8</mosSchema> 
<mosPayload> 

<Owner>SHOLMES</Owner> 
< t r ans i t i onMode >2</transiti onMode > 
<transitionPoint>463</transitionPoint> 
<source>a</ source> 
<des t inat ion>b< /dest inat ion> 
</mosPayload> 
< / mo s Ex t e rna 1 Me t ada t a > 

y : </item> 

fi 

Jr; </story> 

</roStoryReplace> 
</mos> 



4.24 roStoryMove - Move a story to a new position in the piayiist 
Purpose 

This message allows a story to be moved to a new location in a piayiist. The first storylD is the ID of 
the story to be moved. The second storylD is the ID of the story above which the first story is to be 
moved. 



**note**lf the second <storylD> tag is blank move to the bottom. 
Response 
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roAck 
Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

mosID 
ncslD 

roStorvMove 
rolD 
story ID 
storvlD 

Syntax 

< [ELEMENT roStoryMove (roID, storylD, storylD) > 

^xample 

O 

<m>s> 

2 <mosID>aircache .newscenter .com</mosID> 

r. e 5 

nj <ncsID>ncs . newscenter . com</ncsID> 

ff ! | <roStoryMove> 

J <roID>5PM</roID> 

llJ' <StoryID>V: BRIDGE COLLAPSE</StoryID> 
f=| <StoryID>P: PHILLIPS INTERVIEW</StoryID> 
H </roStoryMove> 
</mos> 



4.25 roStorySwap - Swap Positions of Stories in Running Order 
Purpose 

Swaps the Positions of stories and all of their associated Items in the Running Order. 

Response 

roAck 

Port 

MOS Upper Port (10541) - Running Order 



Structural Outline 

mos 

rnosID 
ncsID 

roStorySwap 
rolD 
story ID 
storylD 

Syntax 

< J ELEMENT roStorySwap (rolD, storylD, storylD) > 

Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 

<ncsID>ncs .newscenter . com</ncsID> 
Sj <roStorySwap> 
y <roID>5PM</roID> 

0 <storyID>V: BRIDGE COLLAPSE</storyID> 
<storyID>P: PHILLIPS INTERVIEW</storyID> 

1 y 

W </roStorySwap> 

ffl 

<^/mos> 

1{26 roStoryDelete - Delete Stories from Running Order 

Purpose 

Deletes the referenced Stories and all associated Items from the Running Order. 

Response 

roAck 

Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

mosID 
ncsID 

roStoryDeiete 



rolD 

story! D+ 
Syntax 

< i ELEMENT roStoryDelete (rolD, storyID+) > 

Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 
<ncsID>ncs .newscenter . com</ncsID> 
<roStoryDelete> 

<roID>5PM</roID> 

<storyID>V: BRIDGE COLLAPSE</storyID> 
<storyID>P: PHILLIPS INTERVIEW</storyID> 
</roStoryDelete> 
initios > 

130 ro Control and Status feedback 

f]31 roltemStat - Status of a Single Item in a MOS Running Order 
Purpose 

jlethod for the MOS to update the NCS on the status of an individual Item in a Running Order. This 
flows the NCS to reflect the status of individual Items in the MOS Running Order in the NCS 
Punning Order display. 

Response 

roAck 
Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

mosID 

ncslD 

roltemStat 

rolD 

story ID 

item ID 
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obilD 

status 

time 

Syntax 

< l ELEMENT roItemSt at (roID, storylD, itemID, objID, status, time) > 

Example 

<mos> 

<mosID>aircache .newscenter .com</mosID> 
<ncs ID>ncs . newscenter . com< / ncs ID> 
<roItemStat> 

<roID>5PM</roID> 
<storyID>HOTEL FIRE</storyID> 
<itemID>0</itemID> 
L~ <ob j ID>A02 95< /ob j ID> 
U <status>PLAY< /status > 
gj <time>1999-04-llT14: 13 :53</time> 
</ro!temStat> 



Allows a device, such as prompter, to send a time cue for an Item. 
Description 

This command allows a non MOS or NCS device to send a time cue to the parent Media 
Object Server (or Automation MOS) for a specific Item event. This is not a command to 
execute or play. Instead, this is intended to provide feedback to the parent device as to the 
current execution point of the program. 

The values <moslD>, <rolD>, <storylD>, and <itemlD> are derived from the Item reference 
embedded in a story. The story information is assumed to be transmitted via the roStorySend 



The Media Object Server or automation device that receives this command may use this 
information to update status or generate device triggers. Optionally, the message may be 
redirected to the NCS as a means of providing additional status information. 



4532 roitemCue - Notification of Item Event 




message. 



Response 

roAck 



Port 

MOS Upper Port (10541) - Running Order 
Structural Outline 

mos 

moslD 

ncslD 

roItemCue 

moslD 

roSD 

storyiD 

jfemiP 

roEventType 

roEventTime 
y mosExternalMetadata* 
§ntax 

|%ELEMENT roItemCue {moslD, roID, storyiD, itemID, roEventType, roEventTime, 
rfigjsExternalMetadata* ) > 

« ! ELEMENT roEventType (# PCDATA) > 

<k : !sELEMENT roEventTime (# PCDATA ) > 

Example 

Hi example of a notification message forced to the NCS: 



<mos> 

<mosID>prompt . station . com</mosID> 
<ncsID>ncs . station . com</ncsID> 
<roItemCue> 

<mosID>videoserver . station . group . com</mosID> 
<roID>96857485</roID> 

<storyID>5983A501 : 0049B924 : 83 90EF2B</storyID> 
<itemID>234343234</itemID> 
<roEventType>Prompter</roEventType> 
<roEventTime>2000-03-20T10 : 45 : 00 . 00</roEventTime> 
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<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //ncsA4 . com/mos/supported_schemas/NCSBBBBXML2 . 08</mosSchema> 
<mosPayload> 

<triggeredby>operator</triggeredby> 
<operatorType>prompter</operatorType> 
<net PropDelay> 1 0 < /net PropDelay> 
</mosPayload> 
</mosExternalMetadata> 
</roItemCue> 
</mos> 

An example of a notification message sent to the parent MOS. Note the counterintuitive assignment 
of the parent MOS name to the <ncslD> field: 

4aaos> 

~ <mosID>prompt . station. com</mosID> 

y <ncsID>videoserver . station. group . com</ncsID> 

fy <roItemCue> 

S <mosID>videoserver. station. group . com</mosID> 
J <roID>96857485</roID> 

fU <storyID>5983A501 : 0049B924 : 83 90EF2B</storyID> 

U <itemID>234343234</itemID> 

M <roEventType>Prompter</roEventType> 

<roEventTime>2000-03-20T10 :45 : 00 . 00</roEventTime> 

<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 

<mosSchema>http: //ncsA4 . com/mos/supported_schemas/NCSBBBBXML2 . 08</mosSchema> 
<mosPayload> 

<triggeredby>operator</triggeredby> 
<operatorType>prompter</operatorType> 
<netPropDelay>10</netPropDelay> 
</mosPayload> 
</mosExternalMetadata> 
</roItemCue> 
</mos> 



5of7Q 



12/5/01 4:49 PM 



4.33 roCtrl - Running Order Control 



Purpose 

Allow basic control of a media object server via simple commands such as READY, 
EXECUTE, PAUSE, STOP and SIGNAL 

Description 

The roCtrl message allows control of a running order at three levels, the Running Order itself, Story, and Item. 
The commands READY, EXECUTE, PAUSE and STOP, as well as general indicator, SIGNAL, can be 
addressed at each level. In other words, a single command can begin EXECUTION of an entire Running Order, 
of a Story containing multiple Items, or of a single Item. 

Response 

roAck 

fjj0S Upper Port (10541) - Running Order 

ffi; 

Structural Outline 

ribs 

f moslD 
HicsiD 
RfaCtrl 
E rolD 
t;! story! D 

u ftemiD 
r "" command 

mosExternalMetadata * 

Syntax 

<! ELEMENT roCtrl (rolD, storylD, itemID, command, mosExternalMetadata* ) > 
< ! ELEMENT command (READY | EXECUTE | PAUSE | STOP | SIGNAL) > 

Example 

<mos> 

<mosID>aircache .newscenter . com</mosID> 
<ncsID>ncs .newscenter . com</ncsID> 
<roCtrl> 
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<roID>3dedde9jd</roID> 
<storyID>A3f ds3d</storyID> 
<itemID>3 0848</itemID> 
< c ommand > EXECUTE < / c ommand > 
</roCtrl> 
</mos> 



4.40 ro Metadata Export 

4.41 roStorySend - Send Story information, including Body of the Story 
Purpose 

This message enables sending the body of story from the NCS to Media Object Server. Item 
references (storyltem) are embedded within the story's text. These item references are not intended 
tabe displayed on the prompter, but instead can optionally be used to send a message ( roltemCue ) 
t&Jthe media object server indicated in the embedded reference. Composed from information in the 
embedded item reference, the roltemCue message could be generated by the prompter as this 
ftlden text ( storyltem ) scrolls past the imaginary execution/read line of the prompter display. 

ftee storyltem information can also optionally allow the prompter vendor to display the length of the 
embedded object and perhaps even a countdown. 

Prompters, radio systems, external archive systems, accounting systems, and potentially other 
^sterns and devices can make use of this information. 

Response 

rjgAck 
Port 

MOS Upper Port (10541) - Running Order 



Structural Outline 

mos 

rnoslD 
ncslD 

roStor ySend 
rolD 
story ID 
storySlug? 
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storyNum ? 

storvBodv 
storyPresenter * 
storvPresenterRR * 

J! 
em * 

tab* 

fif 

pkq* 

b* 

I* 

U* 

storyltem* 
itemlD 
itemSlug? 
obi ID 
moslD 

mosAbstract? 

itemChannel? 

itemEdStart? 

itemEdDur? 

ifemTriqqer ? 

macroln? 

macroOut? 

mosExternalMetadta* 



Syntax 

£J ELEMENT roStorySend (roID, storylD, storySlug?, storyNum?, mosExternalMetadata* 
||oryBody) > 

< I ELEMENT storyBody (storyPresenter*, storyPresenterRR* , p*, storyltem*) > 
< ! ELEMENT storyPresenter {# PCDATA) > 
<! ELEMENT storyPresenterRR (# PCDATA) > 

< 'ELEMENT storyltem (itemlD, itemSlug?, objID, moslD, mosAbstract?, itemChannel?, 
itemEdStart?, itemEdDur?, itemTrigger? , macroln?, macroOut?, mosExternalMetadata* ) > 

< I ELEMENT p (# PCDATA | em | tab | pi | pkg | b | i | u)*> 

<! ELEMENT pi (# PCDATA | b | i | u) *> 

< I ELEMENT pkg {# PCDATA | b | i | u) *> 

< ! ELEMENT b (# PCDATA | i | u) *> 

< I ELEMENT i (# PCDATA | b | u) *> 

<! ELEMENT u (# PCDATA | b | i) *> 



Example - RoStorySend 



of 79 



12/ V01 4:40 PM 



In order to apply roStorvSend to implementation of a prompter, you must use this message in 
conjunction with an roCreate message which sends all stories to the prompter from the Running 
Order (Forced Play List Construction), not just stories which contain the prompter's MOS ID. This 
establishes a list of all story ID's and pointers in the order they will air for the associated running 
order. The prompter uses this information to sequence the story information sent in the roStorvSend 
message. 

RO messages, such as roCreate , roStorvlnsett roStorvDelete , etc. should be sent before the 
roStorvSend messages. RoStorvSend messages can be sent alone after the story is initially 
referenced in an RO message (e.g. after roCreate or roStorvlnserfl if only the body of the story has 
changed and not it's position within the Running Order. 

<mos> 

<mosID>prompt . station . com</mosID> 

<ncsID>ncs . station . com</ncsID> 

<roStorySend> 

<roID>96857485</roID> 
M <storyID>5983A501:0049B924:8390EFlF</storyID> 
«f <storySlug>Show Open</storySlug> 

Q <storyNum>C8</storyNum> 

01 

fs\ <mosExternalMetadata> 

^ <mosScope>PLAYLIST</mosScope> 

n <mosSchema>http : / /NCSA4 . com/mos/supported_schemas/NCSAXML2 . 08</mos Schema > 

p.i <mosPayload> 
^ <Owner>SHOLMES</Owner> 
p <changedBy>MPalmer</changedBy> 
<length>463</length> 
<show>10 pm</show> 
< /mosPayload> 
< /mosExternalMetadata> 
<storyBody> 

<storyPresenter>Suzie</storyPresenter> 

<storyPresenterRR>10</storyPresenterRR> 

<p> 

<pi> Smile </pi> 
</p> 

<p> Good Evening, I'm Suzie Humpries </p> 
< storyPresenter>Chet < /storyPresenter> 
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<storyPresenterRR>12</storyPresenterRR> 

<p> - and I'm Chet Daniels, this is the 5PM news on Monday November 5th.</p> 
<p>First up today - a hotel fire downtown</p> 
<item> 

<itemID>l</itemID> 
< items lug>Hotel Fire vo</itemSlug> 
<obj ID>M000705</obj ID> 
<mosID>testmos</mosID> 

< i t emEdS t art > 0 < / i t emEdS t art > 

< i t emEdDur >800</it emEdDur > 
<macroln>c0l/104/dve07</macroln> 
<macroOu t > r 0 0 < / macroOu t > 
<mosExternalMetadata> 

<mosScope>PLAYLIST</mosScope> 
0 <mosSchema>http: //MOSA4 . com/mos/ suppor ted_s enemas /MOSAXML2 . 08</mosSchema> 

£J <mosPayload> 
% I < 0 wne r > S HOLME S < / Owne r > 

ly < trans i t ionMode>2 < /trans it ionMode > 

m 

9 < t r ans i t ionPo i nt > 4 6 3 < / 1 r ans itionPoint> 

<source>a</source> 
jW <destination>b</destination> 
Q </mosPayload> 
r ~* </mosExternalMetadata> 
</item> 

<p>...as you can see, the flames were quite high. </p> 
</storyBody> 
</roStorySend> 
</mos> 



:-...-L 



5.0 Other messages and data structures 

5.1 heartbeat - Connection Confidence Indicator 

Purpose 
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Message sent for the purpose of verifying network and application continuity. 



Response 

heartbeat 
Port 

MOS Lower Port (10540) - Media Object Metadata 
MOS Upper Port (10541) - Running Order 

Structural Outline 

mos 

mosIP 
ncsID 
heartbeat 
time 



Syntax 

|3 ELEMENT heartbeat (time) > 

Example 

51 

ffflOS> 

! i <mosID>aircache . newscenter . com</mosID> 
2? <ncsID>ncs . newscenter . com</ncsID> 
U ^heartbeat > 

s <time>1999-04-llT17: 20 :42</time> 

y e < /heartbeat > 

k/fmos> 

O 

S.2 reqMachlnfo - Request Machine Information 
Purpose 

Method for an NCS or MOS to determine more information about it's counterpart. 
Response 

listMachlnfo 
Port 

MOS Lower Port (10540) - Media Object Metadata 
MOS Upper Port (10541) - Running Order 

Structural Outline 

mos 



mosID 
ncslD 

regMachinfo 
Syntax 

<! ELEMENT reqMachlnfo EMPTY > 

Example 

<mos> 

<mosID>aircache .newscenter . com</mosID> 
<ncsID>ncs .newscenter . com</ncsID> 
<reqMachInf o/> 
</mos> 



3.28 listMachlnfo - Machine Description List 
Purpose 

fiethod for an NCS or MOS to determine more information about it's counterpart. 
Response 



Port 

MOS Lower Port (10540) - Media Object Metadata 
ftbS Upper Port (10541) - Running Order 

Structural Outline 

mos 

mosiP 
ncslD 

listMachlnfo 
manufacturer 
model 
hwRev 
swRev 
DOM 
SN 
ID 
time 

opTime? 
mosRev 

mosExternalMetadata* 



Syntax 



< I ELEMENT listMachlnf o (manufacturer, model, hwRev, swRev, DOM, SN, ID, time, opTime?, 
mosRev, mosExternalMetadata* ) > 



Example 

<mos> 

<mosID>aircache . newscenter . com</mosID> 
<ncsID>ncs . newscenter . com</ncsID> 
<listMachInf o> 

<manufacturer>RadioVision, Ltd. </manuf acturer> 

<mode 1 >TCS 6 0 0 0 < /mode 1 > 

<hwRev>< /hwRev> 

<swRev>2 .1.0 . 37</swRev> 

<DOMx/DOM> 

<SN>92 774892 7</SN> 

<ID>airchache . newscenter . com</ID> 
<time>1999-04-llT17:20 :42</time> 
<opTime>1999-03-01T23 : 55 : 10</opTime> 
<mosRev>2 . 5</mosRev> 
</listMachInfo> 
</mos> 



f}4 mosExternalMetadata - External Metadata 

if 33 * 

Purpose 

ijfiis data block can appear in several messages as a mechanism for transporting additional 
petadata, independent of schema or DTD. 

Behavior 

The value of the <scope> tag implies through what production processes this information should 
Mvel. 

A scope of "OBJECT implies this information is generally descriptive of the object and appropriate for 
queries. 



A scope of "STORY" suggests this information may determine how the Object is used in a Story. For 
instance, Intellectual Property Management. This information should be stored and used with the 
Story. 



A scope of "PLAYLISF suggests this information is specific to describing how the Object is to be 
published, rendered, or played to air and thus, should be included in the Play List in addition to the 
Story. 



This mechanism allows us to roughly filter external metadata and selectively apply it to different 
production processes and outputs. Specifically, it is neither advisable nor appropriate to send large 
amounts of inappropriate metadata to the Playlist in roCreate messages. In addition to these blocks 
of data being potentially very large, the media Object Server is, presumably, already aware of this 
data. 



The value of the <mosSchema> tag should be descriptive of the schema used within the 
<mosPayload>. The value of <mosSchema> is implied to be a pointer or URL to the actual schema 
document. 



The contents of <mosPayload> must be well formed XML, regardless of the schema used. 



Structural Outline 

mosExternalMetadata 
mosScope? 

six:: 

0 mosSchema 
mosPavload 



Syntax 

4? [ELEMENT mosExternalMetadata (mosScope?, mosSchema, mosPayload> 

piote: value of mosSchema is recommended to be a URI - the right most element of which is 
^nsidered significant and uniquely identifying for the purposes of validation) 



Example 

<mosExternalMetadata> 

<mosScope>STORY</mosScope> 
<mosSchema>http : / /ncsA4 . com/mos/ support ed_schemas/NCSAXML2 . 08 </mos Schema > 

<mosPayload> 

< Owne r > SHOLME S < / 0 wne r > 

<ModTime>20010308142001</ModTime> 

<mediaTime>0</mediaTime> 

<TextTime>278</TextTime> 

<ModBy >L JOHNSTON < /ModBy> 



1775/01 



< Approved> 0 < / Approved> 

<Creator>SHOLMES</Creator> 

</mosPayload> 
</mosExternalMetadata> 



5.5 item - Metadata block transferred by ActiveX Controls included in roCreate 
messages 

Purpose 

This data block appears in the MOS Protocol as a subset of the roCreate commands, but may also 
stand alone as recommended mechanism for transferring Item information from an NCS plug-in to 
the NCS. It is implied that this format will also be included in the body of the Story and thus will be 
output in the roStorySend messages. 

Behavior 

The metadata in the Item Reference is a description of how to execute playback or instantiation of an 
#ject, pointed to by the <objlD>. The <moslD> is required for forced playlist construction, 
liaintenance of Item References within stories and for association with MOS ActiveX components. 
TJie <mosAbstract> field provides a displayable abstract of the Object/Item, more verbose than the 
<ftemSlug>. <mosAbstract> may contain formatting. 

m 

(t is recommended that vendor or site specific tags be included in the <mosExternalMetadata> 
flructure, not in the body of the message. 

Structural Outline 

Eem 
item ID 
itemSluq? 
obilD 
mosID 

mosAbstract ? 

itemChannei? 

itemEdStart ? 

itemEdDur ? 

itemTriqqer? 
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macroin? 
macroOut? 

mosExternalMetadata* 
Syntax 

<! ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract? , itemChannel? , 
itemEdStart?, itemEdDur?, itemTrigger? , macroin?, macroOut?, mosExternalMetadata*) 

Example 

<item> 
<itemID>l</itemID> 

<itemSlug>Man Bites Dog vo</itemSlug> 
<obj ID>34323</obj ID> 
HmosID>ncs . com</mosID> 

SmosAbstract>Man Bites Dog vo trt :48</mosAbstract> 
Jgi i t emChanne 1 > 1 < / i t emChanne 1 > 



<mosScope>PLAYLIST</mosScope> 
<mosSchema>http: //mosA4 . com/mos/supported_schemas/MOSAXML2 . 08</mosSchema> 

<mosPayload> 
<source>production</ source> 
<machine >A5 < /machine > 
</mosPayload> 
<mosExternalMetadata> 
<item> 




|UitemEdStart>0</itemEdStart> 
Sit emEdDur >1440</it emEdDur > 



?<itemTrigger>manual</ itemTrigger > 



Wmacroln>2e9de</macroln> 



f^macroOut >23 99a</macroOut> 



N:mosExternalMetadata> 



6. Field Descriptions 



Many of the terminal elements are constrained in size and/or content as listed below. Character 
entities count as one character in size constraints. Numeric values may be provided in decimal or 
hexadecimal (when preceded by "Ox", or "x"). Text constants are case sensitive. 



Bold face type: Specifies that text between tags is in boldface type, 
changed 

Changed Time/Date: Time the object was last changed in the MOS. Format is 
YYYY-MM-DDThh:mm:ss[,ddd]rZl, e.g. 1999-04-1 1T1 4:22:07,1 25Z or 
1999-04-1 1T1 4:22:07, 125-05:00. Parameters displayed within brackets are optional. [,ddd] 
represents fractional time in which all three digits must be present. [Z] indicates time zone 
which can be expressed as an offset from UTC in hours and minutes. Optionally, the 
timezone may be replaced by the character T to indicate UTC. 

changedBy 

Mr 

2 Last Changed by: Name of the person or process that last changed the object in the MOS. 
JS This can be stored in a language other than English. 

lommand 

S roltemCtrl command: The commands READY, EXECUTE, PAUSE and STOP, as well as 

general indicator, SIGNAL, can be addressed at each MOS Structure level. In other words, a 
|* single command can begin EXECUTION of an entire Running Order, of a Story containing 
ill multiple Items, or of a single Item. 

Seated 

Creation Time/Date: Time the object was created in the MOS. Format is 
YYYY-MM-DDThh:mm:ss[,ddd]['Z , ] ) e.g. 1 999-04-1 1T1 4:22:07, 125Z or 
1999-04-1 1T1 4:22:07, 125-05:00. Parameters displayed within brackets are optional. [,ddd] 
represents fractional time in which all three digits must be present. ['Z'] indicates time zone 
which can be expressed as an offset from UTC in hours and minutes. Optionally, the 
timezone may be replaced by the character 'Z' to indicate UTC. 



createdBy 

Created by: Name of the person or process that created the object in the MOS. This can be 
stored in a language other than English. 128 chars max. 

description 

Object Description: Text description of the MOS object. No maximum Length is defined. This 
can be stored in a language other than English. 

DOM 
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Date of Manufacture. 

em 

Emphasized Text: markup within description and p to emphasize text. 
hwRev 

HW Revision: 128 chars max. 

I 

Italics: Specifies that text between tags is in Italics. 

ID 

Identification of a Machine: text. 128 chars max. 

item 

£ Item: Container for item information within a Running Order message. 
ilfmChannel 

|j Item Channel: Channel requested by the NCS for MOS to playback a running order item. 1 28 
y chars max. 

itemEdDur 

ftl Item Editorial Duration: in number of samples OXFFFFFFFF max. 
jtemEdStart 

Editorial Start: in number of samples OXFFFFFFFF max. 

item ID 

Item ID: Defined by NCS, UID not required. 128 chars max. 
itemSlug 

Item Slug: Defined by NCS. 128 chars max 
itemTrigger 

Item Air Trigger: "MANUAL", "TIMED" or "CHAINED". 
CHAINED (sign +/-) (value in # of samples) 

CHAINED -10 would start the specified clip 10 samples before the proceeding clip ended. 
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CHAINED 10 would start the specified clip 10 samples after the preceding clip ended, thus 
making a pause of 10 samples between the clips. There is a space character between the 
word CHAINED and the value. 

macroln 

Macro Transition In: Defined by MOS. 128 chars max. 
macroOut 

Macro Transition Out: Defined by MOS. 128 chars max. 
manufacturer 

Manufacturer: Text description. 128 chars max. 

model 

Model: Text description. 128 chars max. 
njodifiedBy 

n Modified by: Name of the person or process that last modified the object in the MOS. This can 
n be stored in a language other than English. 128 chars max. 

mosAbstract 

ill 

m Abstract of the Object intended for display by the NCS. This field may contain HTML and 
b DHTML markup. The specific contents are limited by the NCS vendor's implementation. 
M Length is unlimited but reasonable use is suggested. 

hiosID 

P MOS ID: Character name for the MOS unique within a particular installation. 
mosGroup 

This field is intended to imply the name of a destination, group or folder for the Object pointer 
to be stored in the NCS. 128 chars max. 

mosRev 

MOS Revision: Text description. 128 chars max. 
mosScope 

This field implies the extent to which the mosExternalMetadata block will move through the 
NCS workflow. Accepted values are "OBJECT' "STORY" and "PLAYLIST" 

ncsID 

NCS ID: Character name for the NCS unique within a particular installation. 128 chars max. 
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objAir 

Air Status: "READY" or "NOT READY". 
objDur 

Object Duration: The number of samples contained in the object. For Still Stores this would be 
1 . OXFFFFFFFF MAX 

objID 

Object UID: Unique ID generated by the MOS and assigned to this object. 128 chars max. 
objRev 

Object Revision Number: 999 max. 
objSlug 

Object Slug: Textual object description. 128 chars max. 

(fbjTB 

O Object Time Base: Describes the sampling rate of the object in samples per second. For still 
m stores this is 0. For PAL Video this would be 50. For NTSC it would be 60. For audio it would 
fjj reflect the audio sampling rate. Object Time Base is used by the NCS to derive duration and 
LJ other timing information. OXFFFFFFFF MAX 

objType 

pf Object Type: Choices are "STILL", "AUDIO", "VIDEO". 
<|jTime 

^ Operational Time: date and time of last machine start. Format is 

YYYY-MM-DDThlrmm^st.dddjt'Z'], e.g. 1999-04-1 1T1 4:22:07, 125Z or 
1999-04-1 1T14:22:07,125-05:00. Parameters displayed within brackets are optional. [,ddd] 
represents fractional time in which all three digits must be present. ['Z'] indicates time zone 
which can be expressed as an offset from UTC in hours and minutes. Optionally, the 
timezone may be replaced by the character 'Z' to indicate UTC. 



Paragraph: Standard html delimitation for a new paragraph. 

pause 

Item Delay: Requested delay between items in ms OXFFFFFFFF MAX. 



Presenter instructions: Instructions to the anchor or presenter that are not to be read such as 
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"Turn to 2-shot." 



pkg 

Package: Specifies that text is verbatim package copy as opposed to copy to be read by 
presenter. 

roAir 

Air Ready Flag: "READY" or "NOT READY". 
roChannel 

Running Order Channel: default channel requested by the NCS for MOS to playback a running 
order. 128 chars max. 

roCtrlCmd 

Running Order Control Command: READY, EXECUTE, PAUSE and STOP, as well as general indicator, 
SIGNAL, can be addressed at each level. In other words, a single command can begin EXECUTION of an 
Ittire Running Order, of a Story containing multiple Items, or of a single Item. 

pOtrlTime 

m Running Order Control Time: roCtrlTime is an optional field which provides a mechanism to 

p time stamp the time of message transmission, or optionally, to provide a time in the immediate 

m future at which the MOS should execute the command. Format is 

T YYYY-MM-DD , T'hh:mm:ss[,ddd][ l Z'], e.g. 1999-04-1 1T1 4:22:07, 125Z or 

I* 1999-04-1 1T1 4:22:07,1 25-05:00. Parameters displayed within brackets are optional. [,ddd] 

nj represents fractional time in which all three digits must be present. [*Z'] indicates time zone 

[a which can be expressed as an offset from UTC in hours and minutes. Optionally, the 

O timezone may be replaced by the character 'Z' to indicate UTC. 

roEdDur 

Running Order Editorial Duration: duration of entire running order. Format in hh:mm:ss, e.g. 
00:58:25. 



roEdStart 

Running Order Editorial Start: date and time requested by NCS for MOS to start playback of a 
running order. Format is YYYY-MM-DDThh:mm:ss[,ddd]['Z'], e.g. 1 999-04-1 1T1 4:22:07, 125Z 
or 1999-04-1 1T1 4:22:07, 125-05:00. Parameters displayed within brackets are optional. [,ddd] 
represents fractional time in which all three digits must be present. ['Z'] indicates time zone 
which can be expressed as an offset from UTC in hours and minutes. Optionally, the 
timezone may be replaced by the character T to indicate UTC. 

roEventTime 

Running Order Event Time: Time of the time cue sent to the parent MOS by the NCS for a 
specific item event. 
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roEventType 

Running Order Event Type: The type of event that is being queued in the Running order. 

rolD 

Running Order UID: Unique Identifier defined by NCS. 128 chars max. 

roSlug 

Running Order Slug: Textual Running Order description. 128 chars max. 
roStatus 

Running Order Status: Options are: "OK" or error description. 128 chars max. 
roTrigger 

Running Order Air Trigger: "MANUAL", "TIMED" or "CHAINED", 
tj CHAINED (sign +/-) (value in # of samples) 

m CHAINED -10 would start the specified clip 10 samples before the proceeding clip ended. 
m CHAINED 1 0 would start the specified clip 1 0 samples after the preceding clip ended, thus 
hi making a pause of 1 0 samples between the clips. There is a space character between the 
5 word CHAINED and the value.slug Textual Object ID: This is the text slug of the object and is 
stored in the native language. This can be stored in a language other than English. 1 28 chars 

1=* max. 

us 

; -ST 

w 

P Serial Number: text serial number. 128 chars max. 
status 

Status: Options are "NEW" "UPDATED" "MOVED" "BUSY " "DELETED", "NCS CTRL", 
"MANUAL CTRL", "READY", "NOT READY", "PLAY," "STOP". 

statusDescription 

Status Description: textual description of status. 128 chars max. 

story 

Story: Container for story information in a Running Order message. 
storyBody 

Story Body: The actual text of the story within a running order. 
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storylD 

Story UID: Defined by the NCS. 128 chars max. 
storyltem 

Story Item: An item imbedded into a story that can be triggered when that point in the story is reached in the 
teleprompter. 

storyNum 

Story Number: The name or number of the Story as used in the NCS. This is an optional field originally 
intended for use by prompters. 128 chars max. 

storyPresenter 

Story Presenter: The anchor or presenter of a story within an running order. 
storyPresenterRR 

jf Story Presenter Read Rate: The read rate of the anchor or presenter of a story within a 
ginning order. 

§>rySlug 

y Story Slug: Textual Story description. 1 28 chars max. 

CP 

swRev 

fj Software Revision: (MOS) Text description. 128 chars max. 

^ Tab: tabulation markup within description and p. 
time 

Time: Time object changed status. Format is YYYY-MM-DDThh:mm:ss[,ddd]['Z'], e.g. 
1999-04-1 1T1 4:22:07, 125Z or 1999-04-1 1T1 4:22:07, 125- 05:00. Parameters displayed within 
brackets are optional. [,ddd] represents fractional time in which all three digits must be 
present. ['Z'] indicates time zone which can be expressed as an offset from UTC in hours and 
minutes. Optionally, the timezone may be replaced by the character 'Z' to indicate UTC. 

u 

Underline: Specifies that text between tags is to be underlined. 



7. Recent Changes 
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7.0 Changes to MOS version 2.6 WD-2001 -08-09 

1. Removed second reference to mosExternal Metadata in roStorySend description 

2. DTD reworked with suggestions from Jiri Basek Aveco s.r.o (Jiri.Basek@aveco.com) 

3. DTD also posted to web site at http://www.mosprotocol.com/mos2dot601.dtd 

7.1 Changes from MOS version 2.5 to 2.6 WD-2001 -06-06 



1. Added message for mosltemReplace. 

2. Added message for roMetadataReplace. 

3. Added message for roStorvMove. 

4. Added structure for mosExtemalMetadata. 

5. mosExtemalMetadata structure added to many common elements 

6. DTD was restructured to include new and changed elements. The sequence of definitions was 
also changed. 



7.2 Changes from MOS version 2.0 to 2.5 WD-2000-08-01 

7. Added tag for mosObiCreate. 

8. Added tag for roStorySend . 
U9. Added tag for roltemCue . 
GO. Added tag for roCtrl . 

fell. Clarified Definition of roList and roRea 

5J2. Fixed errors and syntax errors in documentation. 

2|3. Modified Item structure. Description is as follows: 

1 y 

(Modified Item Structure 

purpose 

III 

f~i Allows for identification of the parent Media Object Server when the play list is forcefully 
0 constructed on a machine other than an object's parent Media Object Server, i.e. when 
D a play list is constructed in a MOS Prompter. 

h* 

Description 

The format of the message remains the same. The only change is the optional addition 
of the existing mosID tag. The value of this tag, if appropriately used, is set to the ID of 
the referenced object's parent Media Object Serve. This change is reflected throughout 
all MOS messages which include the <item> structure. 



Structural Outline 



item 
item ID 
itemSiug 
mosID 
obi ID 

itemChannei 

itemEdStart 

itemEdDur 
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itemTrigger 

macroln 

macroOut 



7.3 Changes for MOS 2.0 WD-1 999-05-1 2 

1. Restructured Running Order messages so that running orders contain "stories", which contain 
"items". 

2. Added optional channel assignment tag "itemChannel" following objID in item tag in Running 
Order messages. 

3. Added story tag "story" to Running Order messages to contain storylD and Items. 

4. Changed the name of message types so that messages that are exclusive to the Media Object 
Metadata socket start with "mos" and messages exclusive to the Running Order socket start 
with "ro". 

5. Eliminated Running Order item messages. The same effect can be achieved using Running 
Order story messages. 

6. Changed item slug tag from "slug" to "itemSlug" and added optional "storySlug" tag following 
story tag. 

u 7. Added message "mosReqObj" to allow NCS to request MOS object information for a specific 
« object by objID. Response is "mosObj". 

n8. Added optional tags for Running Order channel, start, duration and trigger (roChannel, 
S roEdStart, roEdDur, roTrigger). Renamed item tags (itemChannel, itemEdStart, itemEdDur, 
S itemTrigger). 

m9. Added message "roReqAII" for MOS to request list of all known running orders from an NCS. 
hi Response is "roListAH" message. 

010. Changed "metadata" tag to "statusDescription" in mosAck and to "description" in mosObj 
* message. 

Hi. Added itemID to "roltemStat" message. 

§ y 

fk Changes from MOS version 1.52 to 2.0 WD-1 999-03-1 7 

eL_k- 

1. Changed tags to XML format. 

2. Added root tag "mos". 

3. Removed space in tags. 

4. Change MOS ID and NCS ID to always be in the same sequence. 

5. Tags must be used in the sequence defined. 

6. Changed capitalization of tags for readability. 

7. Added optional formatting to metadata. 



8. MOS 2.601 DTD 

<!-- MOS. DTD version 2.801 August 9. 2001 --> 

<!-- edited with XML Spy v4.0 NT beta 2 build Jul 26 2001 {http://wwwjimlspy.com) by Mike Pa ! mer {Associated Press) --> 

<i-Thanks to Jin Basek Aveco s.r.o {Jin.Basek@aveco.cona} and the Octopus Team for the following fist of modifications due to or\gm& DTD bugs ; 
1: element "roStorySend" : comma added between ''rrosExiemafMetadata*' and B storyBody* 
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2: element "roStorySend' 1 old version : deactivated 

3: element Item 8 : ending bracket added after "rrajsExtemalMetadata*'' 

4: element "command J : "READY", "EXECUTE", "PAUSE", "STOP", "SIGNAL" are not elements but predefined strings 
5; element "mosObj" ; 'externalData" changed to ,t mosExternalData , 

8: ATTLIST metadata : deactivated, ? should it be changed to ATTLiST mos£xtemalM0tadata ? 
8: element "mosScope* : "object, "story", "playlist" are not elements but predefined strings 
A9: element !, mos ,! : "reqMacNnelnfo" changed to "reqMachinfo* 
A10: element "storyNum" defined 

Additional changes have been made to the formatting and sequence of the elements In order to better match the order of structures presented h 
MOS Protocol document. 



<!-- MOS Message - One message type per message --> 

<!ELEMENT mos (moslD, ncslD, (mosAck | mosObj | mosReqObj | mosReqAll I mosListAll | mosObjCreate | mosltemReplace | roAck | roCreate J 
roReplace | roMetadataRepIace \ roDelete roReq | roList | roReqAll | roListAll | roStat | roReadyToAir roStoryAppend i roStory nsert | roStoryReplace | 
roStoryMove | roStorySwap | roStoryDelete | roItemStat | roltemCue | roCtri | roStorySend | heartbeat | reqMachlnfo | listMachlnfo))> 

<$ELEMENT mosAck (objID, objRev, status, statusDescription)> 

<&EMENT mosObj (objID, objSlug, mosAbstract, objGroup?, objType, objTB, objRev, objDur, status, objAir, createdBy, created, changedBy, changed, 
cQcription, mosExternalMetadata*)> 

<ffi_EMENT mosReqObj (objlD)> 

<fELEMENT mosReqAll (pause)> 

•AHleMENT mosListAll ((objID, objSlug, mosAbstract?, objGroup?, objType, objTB, objRev, objDur, status, objAir, createdBy, created, changedBy, 
cfpnged, description, mosExternalMetadata*)*)> 

^ELEMENT mosObjCreate (objSlug, objGroup?, objType, objTB, objDur?, time?, createdBy?, description?, mosExternalMetadata> 

<f»gLEMENT mosltemReplace (rolD, storylD, item)> 

iltLEMENT roAck (rolD, roStatus, (storylD, item ID, objID, status)*)> 

||l_EMENT roCreate (rolD, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroln?, macroOut?, mosExternal Metadata*, story*)> 
4IELEMENT roReplace (rolD, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroln?, macroOut?, mosExternalMetadata*, story*)> 
<!ELEMENT roMetadataRepIace (rolD, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, mosExternal Metadata?)> 
<!ELEMENT roDelete (rolD)> 
<!ELEMENT roReq (roiD)> 

<! ELEMENT roList (rolD, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroln?, macroOut?, mosExternalMetadata*, story*)> 

<IELEMENT roListAll ((rolD, roSlug?, roChannel?, roEdStart?, roEdDur?, roTrigger?, mosExternal Metadata*)> 

<!ELEMENT roStat (rolD, status, time)> 

<!ELEMENT roReadyToAir (rolD, roAir)> 

<!ELEMENT roStoryAppend (rolD, story+)> 

<!ELEMENT roStorylnsert (rolD, storylD, story+)> 

<! ELEMENT roStoryReplace (rolD, storylD, story+)> 

<!ELEMENT roStoryMove (rolD, storylD, story!D)> 

<!ELEMENT roStorySwap (rolD, storylD, storylD)> 

<!ELEMENT roStoryDelete (rolD, storylD+)> 

<!ELEMENT roStorySend (rolD, storylD, storySlug?, storyNum?, storyBody, mosExternal Metadata*)> 
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<!ELEMENT roltemStat (rolD, storylD, itemID, objID, status, time)> 

<!ELEMENT roltemCue (moslD, rolD, storyiD, itemID, roEventType, roEventTime, mosExternalMetadata*)> 
<1ELEMENT roCtrl (rolD, storylD, itemID, command, mosExternalMetadata*)> 
<!ELEMENT heartbeat (time)> 

<!ELEMENT listMachlnfo (manufacturer, model, hwRev, swRev, DOM, SN, ID, time, opTime?, mosRev, mosExternalMetadata*)> 
<! ELEMENT story (storylD, storySlug?, storyNum?, mosExtemal Metadata*, item*)> 
<!ELEMENT description (#PCDATA | p | em | tab)*> 

<!ELEMENT storyBody (storyPresenter*, storyPresenterRR*, p*, storyltem*)> 

<!ELEMENT storyltem (itemID, itemSlug?, objID, moslD, mosAbstract?, itemChannel?, itemEdStart?, ItemEdDur?, itemTrigger?, macroin?, macroOut?, 
mosExternalMetadata*)> 

<!ELEMENT item (ItemID, itemSlug?, objID, moslD, mosAbstract?, itemChannel?, ItemEdStart?, itemEdDur?, ItemTrigger?, macroin?, macroOut?, 
mosExternalMetadata*)> 

<!ELEMENT mos External Metadata (mosScope?, mosSchema, mosPayload)> 

<!ELEMENT b (#PCDATA 1 1 1 u)*> 

<!ELEMENT i (#PCDATA | b | u)*> 

<!ELEMENT p (#PCDATA | em | tab | pi | pkg | b | i | u)*> 

<!ELEMENT pi (#PCDATA | b | i | u)*> 

ELEMENT pkg (#PCDATA | b | i | u)*> 

JgLEMENT u (#PCDATA | b | i)*> 

<?||LEMENT moslD (#PCDATA)> 

IMlEMENT ncsID (#PCDATA)> 

|S§LEMENT changed (#PCDATA)> 

<$!ELEMENT changedBy (#PCDATA)> 

ELEMENT command (#PCDATA)> 

it valid values for "command" are "READY 8 , "EXECUTE", 'PAUSE 1 , "STOP 8 , "SIGNAL" -> 
SlLEMENT created (#PCDATA)> 
^TfeLEMENT createdBy (#PCDATA)> 
<!ELEMENT DOM (#PCDATA)> 
<!ELEMENT em (#PCDATA)> 
<[ELEMENT hwRev (#PCDATA)> 
<!ELEMENT ID (#PCDATA)> 
<!ELEMENT itemChannel (#PCDATA)> 
<!ELEMENT itemEdDur (#PCDATA)> 
<!ELEMENT itemEdStart (#PCDATA)> 
<!ELEMENT itemID (#PCDATA)> 
<IELEMENT itemSlug (#PCDATA)> 
<! ELEMENT itemTrigger (#PCDATA)> 
<!ELEMENT macroin (#PCDATA)> 
<!ELEMENT macroOut (#PCDATA)> 
<!ELEMENT manufacturer (#PCDATA)> 
<!ELEMENT model (#PCDATA)> 



<!ELEMENT mosAbstract ANY> 
<!ELEMENT mosPayload ANY> 
<!ELEMENT mosSchema (#PCDATA)> 
<!ELEMENT mosScope (#PCDATA)> 

<!- valid values for "mosScope 11 are "OBJECT 55 . "STORY", "PLAYLIST* --> 

<!ELEMENT mosRev (#PCDATA)> 

<!ELEMENT objAir (#PCDATA)> 

<!ELEMENT objDur (#PCDATA)> 

<!ELEMENT objGroup (#PCDATA)> 

<!ELEMENT objID (#PCDATA)> 

<!ELEMENT objRev (#PCDATA)> 

<!ELEMENT objSlug (#PCDATA)> 

<!ELEMENT objTB (#PCDATA)> 

<!ELEMENT objType (#PCDATA)> 

<!ELEMENT opTime (#PCDATA)> 

<iELEMENT pause (#PCDATA)> 

-fjf LEMENT reqMachlnfo EMPTY> 

ISlement roAir (#pcdata>> 
Element roiD (#pcdata)> 

IpLEMENT roChannel (#PCDATA)> 

Element roaricmd (#pcdata)> 

<pLEMENT roCtrlTime (#PCDATA)> 
f ELEMENT roEdDur (#PCDATA)> 
4l|LEMENT roEdStart (#PCDATA)> 
^ELEMENT roEventTime (#PCDATA)> 
<p|LEMENT roEventType (#PCDATA)> 
<pgLEMENT roReqAII EMPTY> 
<!ELEMENT roSlug (#PCDATA)> 
<!ELEMENT roStatus (#PCDATA)> 
<!ELEMENT roTrigger (#PCDATA)> 
<!ELEMENT SN (#PCDATA)> 
<! ELEMENT status (#PCDATA)> 
<!ELEMENT statusDescription (#PCDATA)> 
<!ELEMENT storylD <#PCDATA)> 
<!ELEMENT storyNum (#PCDATA)> 
<!ELEMENTstoryPresenter (#PCDATA)> 
<!ELEMENT storyPresenterRR (#PCDATA)> 
<! ELEMENT storySlug (#PCDATA)> 
<! ELEMENT swRev (#PCDATA)> 
<!ELEMENTtab (#PCDATA)> 
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<!ELEMENT time (#PCDATA)> 
<!- Attributes -> 
<!ATTLIST mos 

version CDATA #FIXED "-//MOS Group//DTD MOS 2.601 //EN" 

changeDate CDATA #FIXED "09 August 2001 " 

> 

<!-- <! ATTLiST metadata xmfrspaee (default j preserve) preserved -> 



8. References and Resources 

8.1 

the primary site for MOS protocol information is htto ://www. mosprotocol .com . 

8.2 XML FAQ 

ljip://www.ucc.ie/xml/ contains an extensive document of Frequently Asked Questions regarding 
XML. 

8.3 Recommended Reading 

list XML: John E. Simpson; 1999. Prentice Hall PTR. ISBN 0-13-9434417-8. ($34.99) 

|£ML for Dummies Quick Reference: Mariva H. Aviram; 1998. IDG Books Worldwide, Inc. ISBN 

§(7645-0383-9. ($14.99) 

the Unicode Standard, Version 2.0: The Unicode Consortium. Addison-Wesley. ISBN 
0-201-48345-9. ($62.95) 

8.4 XML Web Sites 

The mission of XML.com is to help you discover XML and learn how this new Internet technology can 
solve real-world problems in information management and electronic commerce. 

http://www.xml.com/xml/pub/ 

Robin Cover's XML resource page is perhaps the most useful and extensive available on the Web. 

http://www.oasis-open.ora/cover/xml.html 
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GLOSSARY 



OSM Definitions and Functional Descriptions 
Modules 

MOS Protocol Receiver 

Receives Unicode XML text message via TCP/IP Socket and saves each message as a 
file. This module also handles message acknowledgment and transmission of status 
messages passed to the module. 

MOS File Parser 

Validates each XML message and parses appropriate messages for mosObj pointers 
embedded in Item References. 

XML & Object File Storage 

Stores XML files and uses mosObj pointers to retrieve referenced media objects which it 

also stores. 
Business Rules 

Business rules are applied to metadata included in the RO, Story, Item and Object levels. 
These rules primarily control routing of content through the system. Business rules are 
also applied to the current status of transmission modules, level of content storage used in 
the OSM and in remote clients. 

Addressing Module 

The addressing module takes plain language feed and client names and resolves these to 
delivery destinations which may include IP addresses, multi-cast addresses, or file folder 
destinations. 

File Transmit Module 

The file transmit module takes addressing information and uses this to deliver XML and 
Object files to the proper storage location and in the proper format for the chosen 
delivery mechanism to recognize and forward them to the client destinations. 

Internet FTP Interface 

The FTP interface uses control information sent to it from the File Transmit Module to 
determine what files should be sent to remove clients over the Internet or network. This 
module will scale from handling one or two FTP sessions to multiple FTP sessions in the 
first release. 

This interface is also capable of passing information upstream back to the OSM. This 
information should include H&S (Health and Status) as well as the means for support of 
e-commerce models. 
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The interface is able to transmit multiple files simultaneously to individual clients, in 
addition to supporting simultaneous transmission to multiple clients. 



Four possible channels are provided: 



1) roConstruction 

2) roStorySend 



3) low res proxies 

4) high res content 



SkyStream Interface 

The SkyStream interface uses control information sent to it from the File Transmit 
module to determine what files should be sent to remove clients over a satellite 
transmission path. Other control information is also sent from the File Transmit Module 
to the SkyStream interface which may control the level of forward error correction 
applied, the frequency of repetition and priority of files in the queue. 

This interface is also capable of passing information upstream back to the OSM. This 
information should include H&S (Health and Status) as well as the means for support of 
e-commerce models. 

The interface is able to transmit multiple files simultaneously to individual clients, in 
addition to supporting simultaneous transmission to multiple clients. 

Four possible channels are provided: 



OSM Client 
Modules 

Internet FTP Interface 

Works as a client to the OSM Internet FTP interface. 

SkyStream Interface 

Works as a client to the OSM SkyStream interface. 

File Receive Module 

Takes files from the SkyStream and FTP interfaces and stores them to disk. 

MOS File Parser 



1) 

2) 
3) 
4) 



roConstruction 
roStorySend 



low res proxies 
high res content 
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This is the same MOS File Parser as used in the OSM. Validates each XML message and 
parses appropriate messages for mosObj pointers embedded in Item References 

XML & Object File Storage 

Nominally 80 gB or more of storage for both media objects and XML files. 

Business Rule Module 

Nominally, the same engine as used in the OSM or a derivative. Business Rules will 
include purge of media objects no longer referenced in Stories or Running Orders, 
holding of embargoed material, compilation of usage statistics, and transmission of 
statistics and H&S via transmission interfaces. 

ASP Web Server 

The server provides functionality as defined for the Browser UI, specified below. It must 
also handle streaming of the low resolution proxy files. 

This also includes an FTP interface which exposes XML and Object files for other 
devices to retrieve. 

Video Output 

As commanded by the ASP interface, the Video Output plays out the full resolution 
version of the requested object. If the requested object does not exist or has not 
completed transmission, the Video Output module may alternately output the low 
resolution proxy, scaled to full screen if it exists. 

This module is capable of queuing multiple requests and "slating" each playback with 5 
seconds of title and/or other information extracted from Story and Object metadata. 

Optionally, the module is capable of basic Sony Beta Serial Control to cue legacy tape 
machines to record and stop. 

MOS Output 

MOS messages may optionally be forwarded, as appropriate and as they conform to 
business rules, to a local NCS where they can be used to recreate the RO, Stories, and 
Object Pointers. 

Serial Wire Output 

XML Story information can optionally be reformatted via XSL transforms into a number 
of different agency wire transmission formats. These text files are then transmitted via a 
serial interface at a configurable speed. No flow control or feedback is required. 

Web Browser ASP User Interface 

Content Explorer 

The Content Explorer is comprised of some number of ASP pages which present: 
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1) A list of Running Orders 

2) A list of Stories in a selected Running Order 

3) The text of a selected Story 

4) A list of Media Objects in a selected Story 

5) A proxy version of a selected media object 

The Interface allows the user to do general searches on both text and metadata contained 
in media object pointers. The interface must allow remote control play-out of video from 
the server from the Web Browser UL The interface also includes e-commerce functions. 
The interface is updateable via the same transmission mechanisms as are used to transmit 
XML and Object files. 
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